Is learning to write CSS a better use of time than finding and using a
package that produces complete web pages?

I've moved to a new platform (Macintosh), taking with me about 400
personal web pages, some dating back so far I probably wrote them in vi.
About 4 years ago (thanks in part to hints found in this group) I
converted about 80 pages to CSS, and was fairly happy with the result,
plain though they are.  Since then I've forgotten most of what little I
learnt about CSS, since I didn't revise the CSS.  Skimming various Eric
Meyer books has only helped a little so far in bringing me up to date on
CSS.

I am wondering whether writing CSS (and HTML) is still a reasonable
approach to updating old web pages, and writing new ones?  Perhaps it is
time to change to a program that does everything for the web site
creator?  That is, if anything like that exists in the price range I
would consider.  My tests so far have eliminated a dozen or so HTML
editors from the 30 I've downloaded so far.  Also, I am rapidly coming
to the conclusion that looking at HTML editors is entirely the wrong
approach to making web sites.

CSS now seems to me even more confusing than it was four years ago, in
terms of making decisions about what to use.  I have a very simple valid
HTML test page with my test CSS in the document up at
http://www.ericlindsay/sheltersrus/index.html   Even that raises many
questions I can't answer (entirely apart from whether it will work in
anything except Safari and Opera).

Is it reasonable to use HTML 4.01 Strict, or should I look at XHTML?  I
seem to be seeing posts here and elsewhere implying more browser support
problems if I go XHTML.  I did find a page that gave support for
sticking with HTML on  http://www.spartanicus.utvinternet.ie/

Is charset=ISO-8859-1 still reasonable, or should something Unicodey be
used?

Should you really put link rel="icon" href="favicon.ico"
type="image/x-icon" in your header, or leave it out entirely?  Don't all
browsers pick up a favicon in your web base directory anyway?  I guess
that isn't a stylesheet question.

I used to use <base target="_top"> in the head to jump non-Javascript
browsers out of external framesets imposed on your site, but a validator
will complain about that.  Do you ignore the validators, or is there
some other way?

Is * { etc } a reasonable way to include your main CSS styles, or is it
better to have a div id=document around your entire page and style that
instead?  Or should you maybe style the html tag with your main CSS
styles?  I found a discussion that seemed to indicate the * { approach
was a problem.

text-shadow: 5px 5px 10px #11aaaa;  works just fine in Safari, and
doesn't show in Opera (either result is fine by me), but is that sort of
thing likely to break some other browser entirely?

float: right; makes my heading keep out of the way of my logo image
(unless someone makes the page very narrow in their browser), but is
using float for positioning likely to break things in lots of browsers?
And if float isn't a good idea, what is?

color: red; background-color: transparent;  If I put in a color the
validator warns about not having a background-color, but it won't accept
transparent.  I thought transparent was both allowed, and the default.
http://www.w3.org/TR/REC-CSS2/colors.html   I eventually found a thread
on validation about a week ago (my newsgroup reading started from mid
July, the oldest posts available to me via my usual reader).  That at
least explained how using transparent could leave problems with some
combinations of colours, so I can see a warning is justified.  I guess I
might as well leave out the transparent, since it is the default.

.image { border: none; margin-top: 20px; padding-top: 20px; }
img { border: none; float: right; padding-left: 15px; }
This seems very messy.  I wanted each picture to stay to the right of
each associated paragraph, which would be easy if I used a table.
Instead I've added a div class="image" to each paragraph, so I am headed
back to tag soup.  If you make the browser window sufficiently wide the
pictures will align away from the right margin anyhow.  I have the
border: none; (probably only needed in img) because I am pretty sure IE
will try to put a border around both the picture and the padding.  I
thought the default was not to show a border?

In the past I've avoided using images (modem bandwidth and lack of host
site space), but I now I would like to add lots of images.  However it
seems that instead of IMG I should use OBJECT.  Except browser support
may not be there.  Luckily this topic was covered in
http://www.spartanicus.utvinternet.ie/embed.htm

#logo { border: none; position: absolute; top: 0px; left: 10px; width:
100px; }
I wanted the logo (when I get time to draw it) to be displayed in the
traditional top left corner.  But I wanted the first stuff in the
document body to be the h1 and first paragraph, to make things work
better with search engines.  I will always place material for search
engines ahead of graphics or html or scripts or anything else in my page.
But position absolute means I have to make other things like the
sidebar1 start lower on the page.  If someone makes their browser
magnification high enough that will break.  Plus so far I'm not sure I
am not headed for more problems by doing an absolute position.

This bit of stuff styling the footer is just a total disaster, and so
far I have no idea where I am going with it.
#footer p {margin-top: 0; margin-bottom: 0; }
#footer h3 {margin-top: 0; margin-bottom: 0; }
#footer {width: 75%; float: right;  }
.business { color: #dddddd; background-color: transparent; }
h3.business {font-size: 1.5em; }
p.business {font-size: .8em; }

Shouldn't I be able to do #footer h3 p
So far I don't understand why that isn't operating on h3 and p
Obviously something I've missed entirely, but I don't even know what to
search for.  Probably it operates only on the p that is a child of h3,
but so far I have absolutely no mental image of inheritance.  I keep
hoping to find a diagram like the box model ones that explained the
content inside padding inside border inside margin stuff.

Then there is the h3.business and p.business which both work, but
contrast that to these from the #sidebar1
.sb  ul {margin-top: 0; padding-top: 0px; }
where I could only get the sidebar looking reasonable by adding that .sb
class, which seems to me like another piece of tag soup.

I don't want to even think how messy CSS might get when I finally get at
IE on a Windows PC to check what breaks.  Plus so far I haven't even
looked at menus and link styling.

So, anyone feel like commenting on whether I should persist with CSS, or
put the same effort into trying to find a program that will make web
pages for me (probably not in CSS).

--
http://www.ericlindsay.com

Eric Lindsay wrote:
> Is learning to write CSS a better use of time than finding and using a
> package that produces complete web pages?

Best option is not to write CSS, but to use CSS that's already written
by someone else who really knows what they're doing. For a "typical"
site (and I know there are no typical sites) then the "hard work"
problems are all much the same - nav menus, two or three columns, that
sort of thing. If you possibly can, get a good existing CSS and use
that.

Editing packages are bad. There still just aren't any notably good
ones. Dreamweaver writes doggy code, FP is unmentionable. As you
clearly have a good grasp of HTML with vi, then neither would offer
anything that were really going to benefit from.

A CSS-based design is still worth the trouble. Blag it if you can,
learn it from scratch if you must.


For an easy CSS design, design around the standards and see that it
works well with Safari and Firefox. Ignore Mac IE, for it's well
obsolete. You will probably care about Windows/IE and that's the only
browser that still matters, yet doesn't play ball.

If you can avoid horizontal padding and borders entirely, then IE
compatibility is easier. Otherwise you're into the well-known box-width
bugs.

Use consistent size units throughout. Use ems for anything vertical (or
maybe % for relative font sizes) and use either ems or pixels for
horizontal measurements. Either "go fluid" and use ems (probably best),
but be aware that you'll need to be carefully structured to make sure
that you really are fluid for different window and text sizes.
Otherwise if you're heavily involved with fixed-size assets like
images, then go with pixels for horizontal measures and stick with
them. Trying to mix pixels and ems on the horizontal axis is hard work
if they're in close proximity.

Be wary of float. It's not easy to understand the more than trivial
cases and it's a real bug-mine around IE.

Don't be too quick to dismiss tables. If they're justifiable then
they're currently still more cross-browser stable than the alternatives
for "close in" work. Just avoid using them for "page level" design
work.

Do the right usability things, set your size units right, avoid
Verdana, read Joe Clark's usability book.

> Do the right usability things, set your size units right, avoid
> Verdana, read Joe Clark's usability book.

Just out of interest, why avoid Verdana?

Robin Tucker wrote:
 
>
> Just out of interest, why avoid Verdana?

<http://www.google.com/search?hl=en&...G=Google+Search>

--
-bts
-When motorcycling, never follow a pig truck

--
On Mon, 17 Oct 2005 22:48:03 +1000, Eric Lindsay
<NOSPAmar2005@ericlindsay.com> wrote:

> Is learning to write CSS a better use of time than
> finding and using a package that produces complete web
> pages?

I have not found a package that actually works, and
therefore, reluctantly, write in source code.   Handmade
CSS pages are simply better than any alternative I have
found.

> I've moved to a new platform (Macintosh), taking with
> me about 400 personal web pages, some dating back so
> far I probably wrote them in vi. About 4 years ago
> (thanks in part to hints found in this group) I
> converted about 80 pages to CSS, and was fairly happy
> with the result, plain though they are.  Since then
> I've forgotten most of what little I learnt about CSS,
> since I didn't revise the CSS.  Skimming various Eric
> Meyer books has only helped a little so far in
> bringing me up to date on CSS.

I still find CSS largely incomprehensible.  I find some
CSS incantations that produce the desired effect, then
use them.  If Perl is a write only language, CSS is a
read only language.  When one has something that
produces the desired effect, then one can comprehend it,
but to produce something that will result in the desired
effect is hard.

> Is it reasonable to use HTML 4.01 Strict,

This produces the most predictable and controllable
display.

> Is charset=ISO-8859-1 still reasonable, or should
> something Unicodey be used?

Go with utf-8


--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
mowhtnaqV6gPbNE2uGxqyenU7LD+yyEd4JhXfU5T
4ONZXpYNo3mzGRpxN3KCGawYxSvH1W0/QjSSsihtd


--
http://www.jim.com

On Mon, 17 Oct 2005, Eric Lindsay wrote:

> Is learning to write CSS a better use of time than finding and using
> a package that produces complete web pages?

Even if I could find a package that I trusted to produce HTML and CSS
for me, I'd still want to understand HTML and CSS, at least far enough
to be able to be confident that the package was behaving halfways
sensibly.  Wouldn't you?

[...]
> Is it reasonable to use HTML 4.01 Strict, or should I look at XHTML?

Isn't this a stylesheets group, not an HTML one?  That question has
been exercised numerous times, even recently, in its proper place: I
doubt that exercising it yet again is going to produce any fresh
insights.

> Is charset=ISO-8859-1 still reasonable,

For CSS?  I'd recommend us-ascii, though you aren't asked to declare
it as such.

For HTML, I have some recommendations which maximise compatibility
with older browsers, depending on what you want/need to achieve in
the way of character repertoire:
http://ppewww.ph.gla.ac.uk/~flavell/charset/checklist

Work your way down until you hit the repertoire etc. that you need,
and there you are.

If, on the other hand, you want to maximise the character repertoire
which you can use, and you don't care for old browsers much, except
perhaps NN4: then, if you are competent to use utf-8, then use it (#s7
in the above checklist), otherwise use #s6 .

[...]
> float: right; makes my heading keep out of the way of my logo image
> (unless someone makes the page very narrow in their browser), but is
> using float for positioning likely to break things in lots of
> browsers?

Floating is useful, and less likely to break horribly than any kind of
explicit positioning; but the results aren't always quite as
predictable as some might wish, and then they worry about the
potential untidiness of the result.  It's up to you, really.

> color: red; background-color: transparent;

Been discussed several times recently.  Feel free to read the group -
write-only postings aren't so productive.

> That at least explained how using transparent could leave problems
> with some combinations of colours, so I can see a warning is
> justified.

Indeed.  I'm not certain whether this effect is intentional, or, as
some have suggested, a bug in the W3C CSS checker; but, either way, I
reckon a warning is justified for that reason.

> I guess I might as well leave out the transparent, since
> it is the default.

Unless you're worried about getting a bg. image to show through from
the underlying element, I'd say re-specify the underlying colour.

If it -is- about an underlying background image, then, IMHO, just live
with the warning.  But an unlucky clash with a hostile stylesheet
could make parts of the page unreadable (it could be the user's own
stylesheet, or an unexpected change in your company's mandatory
corporate stylesheet if you're in such a situation), in a way that
conforming to the rule - which says basically you should only set text
colour *with* background colour, or neither of them, but never just
the one, at any given specificity) could protect against.  Of course
the other cascaded stylesheets are supposed to be following that same
rule, or the bets are off.

> In the past I've avoided using images (modem bandwidth and lack of host
> site space), but I now I would like to add lots of images.  However it
> seems that instead of IMG I should use OBJECT.

In theory, yes, but a certain browser vendor contrived to make it far
too iffy.  I still reluctantly stay with IMG for normal web use, even
though I've considered it obsolete ever since the draft HTML/3.0 <fig>
markup.

> Except browser support may not be there.  Luckily this topic was
> covered in http://www.spartanicus.utvinternet.ie/embed.htm

A reliable informant in many regards, indeed, especially about
practicalities.

> So, anyone feel like commenting on whether I should persist with
> CSS,

Without question.

> or put the same effort into trying to find a program that will make
> web pages for me

Possibly, but only if it uses current best practice, i.e strict or
strict-ish (X)HTML, whichever you choose, for structure, and CSS for
presentation proposal(s).

> (probably not in CSS).

That would be a big mistake!  But by asking here, I guess you
guaranteed that answer.

In article <1129556012.899230.161200@g44g2000cwa.googlegroups.com>,
dingbat@codesmiths.com wrote:

> Eric Lindsay wrote: 
>
> Best option is not to write CSS, but to use CSS that's already written
> by someone else who really knows what they're doing.

Excellent advice.  Actually before reaching your reply I found myself
making a Template directory and downloading sample CSS pages from
Stephen Poley's interesting site.
http://www.xs4all.nl/~sbpoley/webmatters/  One problem with using
existing CSS is that I found some sites offering CSS examples for free
download that didn't  seem significantly better than the mess I am
currently producing myself.

> Editing packages are bad. There still just aren't any notably good
> ones.

I don't think I would do enough pages to justify the cost of
Dreamweaver, even if it produced perfect results.  I mainly viewed it of
interest for the site template facilities rather than for the code it
produced.  However my only experience of it was back with DW3.  I'm on a
Mac, so FP probably isn't an option anyhow, but its old reputation
doesn't encourage me to check.

I do wonder whether instead of a HTML editor, I shouldn't consider
instead a CSS editor.  I've had a quick look at two, and both turned out
to be cross platform.

http://www.hostm.com/css/  Simple CSS is freeware.  Create cascading
style sheets from scratch, modify existing ones. CSS2.  For Linux, Mac,
Windows.  If you already know CSS this may be pretty handy for avoiding
typos, although all the selecting from menus would get tiresome quickly.
I thought it difficult if you didn't know CSS.

http://www.westciv.com  Stylemaster CSS v4, Mac and Windows.  Shareware
US$60 30 day demo.  Wizards, 30 templates, CSS tutorial, excellent
website support, validation, preview any document.  Written by CSS
specialist John Allsopp.  The embedded lessons took a couple of hours to
lead me through using lots of the editor functions to create a more
elaborate style sheet than I could have done.  I was impressed by the
CSS courses that are available from the same source, one of which comes
with the package.  I think I'd have to go through several lessons before
I got any great speed with Stylemaster.  But having a live preview of
the results, the code you are creating, and the structure of the
document seems a good way of learning more.  You can edit either at the
structure or in the CSS.

>Ignore Mac IE, for it's well obsolete. You will probably care about
Windows/IE

I was planning to ignore Mac IE, however my site logs show I have to
work with Windows IE, and possible relatively old versions of it even.
I wish I could ignore earlier versions.  Guess I'll do some careful
looking at the stats as soon as I get a chance.  Or maybe there are some
web wide stats on browser use.  I'll Google that.

> If you can avoid horizontal padding and borders entirely, then IE
> compatibility is easier.

I used padding to the left of my photos, just to keep the text clear of
them.  That sounds like I may have to rethink.  Or can I get away with
using margins?

> Use consistent size units throughout. Use ems for anything vertical (or
> maybe % for relative font sizes) and use either ems or pixels for
> horizontal measurements. Either "go fluid" and use ems (probably best),
> but be aware that you'll need to be carefully structured to make sure
> that you really are fluid for different window and text sizes.

I used ems for text, and % for div widths.  I recall some discussion of
possible problems with ems, so I guess I should go with % for text sizes
also.

> Otherwise if you're heavily involved with fixed-size assets like
> images, then go with pixels for horizontal measures and stick with
> them.

Depending on how many thumbnails I use, I'll probably eventually want to
provide pixel sizes on img just to make display calculations easier for
browsers.  I left thumbnail sizes out for my test page.  I want the
layout to be fluid, but obviously I break things if someone does 400%
magnification of the page while in a narrow browser window.  However I
will mostly just want images to end up lined up on one side or the other
of a page.  I'm not going to try to stitch images together from other
images.

> Be wary of float. It's not easy to understand the more than trivial
> cases and it's a real bug-mine around IE.

I'm not sure how you manage columns without float left and float right,
unless I use tables

> Don't be too quick to dismiss tables.

I'm not going to discard tables if I have column data.  I even wrote a
little shell script that makes a html table, to make it easier for me to
enter collections of figures I didn't already have in electronic form.
But I would like to avoid them in general layout, if I can.

> Do the right usability things, set your size units right, avoid
> Verdana, read Joe Clark's usability book.

Oh yes, Verdana.  Now I remember the problem of it looking so big
relative to other fonts.  Plus Stephen Poley mentioned above had an
article everyone is quoting.  I'll put Verdana as third choice in my
font suggestions.  I don't think I want to avoid suggesting a sans-serif
font in many of my pages, but I will change things to avoid suggesting
anything except relative font sizes (in %).

Thanks for your suggestions.

--
http://www.ericlindsay.com

In article <Pine.LNX.4.62.0510172204400.8397@ppepc56.ph.gla.ac.uk>,
"Alan J. Flavell" <flavell@ph.gla.ac.uk> wrote:

> Even if I could find a package that I trusted to produce HTML and CSS
> for me, I'd still want to understand HTML and CSS

Well, yes I'd prefer to understand HTML and CSS, but it all comes down
to lacking the time (and ability) to handle a TOE.  I think I'm going to
have to go with a partial understanding of CSS, and simply decide to
ignore all the bits I don't think I'm likely to use.  In HTML, I don't
use frames for anything, and don't understand how to use them, so I
guess I will decide to ignore great slabs of CSS where it seems I'm
unlikely to use those capabilities.
 
> Isn't this a stylesheets group, not an HTML one?
Sorry about that.  The whole topic of handling web sites is such a mixed
up mess in my head at the moment that it was just as likely that I would
have put in a question about calibrating CMYK profiles vs sRGB profiles
and think I was in the right group.  I'll try to be more careful about
sticking only to the CSS side.

> Is charset=ISO-8859-1 still reasonable,
> For HTML, I have some recommendations which maximise compatibility
> with older browsers, depending on what you want/need to achieve in
> the way of character repertoire:
> http://ppewww.ph.gla.ac.uk/~flavell/charset/checklist

Thank you.  That is a wonderful checklist.  Told me exactly what I
needed to know.  With so much of the Macintosh now using UTF-8 by
default, I'll wait until I have committed to an editor before deciding
whether to change from ISO-8859-1.  With many of the editors calling the
system wide text handling, I'll probably decide on UTF-8 as per your #s7
if I end up using such an editor.

> Floating is useful, and less likely to break horribly than any kind of
> explicit positioning; but the results aren't always quite as
> predictable as some might wish, and then they worry about the
> potential untidiness of the result.  It's up to you, really.

I want the design to be fluid, so I can accept untidy.  I think I might
get some balloons printed with text, and suggest to anyone who objects
to the page being mutable that they try to confine a balloon to the same
precise appearance no matter what size it is.

> Unless you're worried about getting a bg. image to show through from
> the underlying element, I'd say re-specify the underlying colour.

Well, OK.  I guess I'd have to leave specifying the background-color
until most of the other design colors, and the general background is
stable are stable.  Otherwise I can see repeated changes to a number of
spots in the CSS, especially if a design gets elaborate.

> If it -is- about an underlying background image, then, IMHO, just live
> with the warning.

I've used an underlying background image on a few pages, and have found
it a handy technique for getting some results.  Don't think I'll ever be
a heavy user.
 
>
> Possibly, but only if it uses current best practice, i.e strict or
> strict-ish (X)HTML, whichever you choose, for structure, and CSS for
> presentation proposal(s).
> 
>
> That would be a big mistake!  But by asking here, I guess you
> guaranteed that answer.

I guess I did guarantee that answer.  There are still a few We Do
Everything web page generators for the Macintosh that I want to check
out.  http://www.realmacsoftware.com/rapidweaver/  Rapid Weaver v3.2,
Cocoa Shareware US$35. Valid XHTML and CSS, themes based visual editor,
smart publishing, iPhoto integration.  In October I saw a little web
site that looked very clean, so I opened up the source (as you do).
That was very clean, all valid code, and tidier than I do by hand (which
is generally pretty clean).  It was made by Rapid Weaver.  I think I'll
need to take another look at it to work out why I rejected Rapid Weaver
initially.  Maybe their template are too limited, but since you can make
your own templates ...

--
http://www.ericlindsay.com

Eric Lindsay wrote:

> Valid XHTML and CSS

"Valid (X)HTML and CSS" is of course a basic essential requirement for
an "automated" editing tool, even though few achieve it. It's hardly
something to crow about!

Mainly though, mere validity just isn't enough. Validity is
monkey-work, I want quality too. There needs to be _intelligence_
behind competent CSS work and there are no current tools providing it.

The failing of Dreamweaver (NB SpaceGirl) is that its notion of "CSS"
is pathetically fragmented. Like all of these tools that I've seen it
does no more than use the same old <font> markup shoved into a style
attribute. It's a syntactic translation, not any real shift in
structure or likely benefit. There's no inherent concept of class or
_organisation_ of styles into coherent groups. A major benefit of CSS
is this decoupling of selection rule and applied styles (although OO
programmers will recognise how this fails to work in CSS, but that's a
separate problem). If CSS (as generated by DW) is reduced to little
more than applying individual rules to individual elements, then that's
no better a quality of markup than <table>s and <font>s were.

I'd also be wary of XHTML tools in general. Although there's nothing
_wrong_ with choosing it, it would immediately make me suspicious of
clueless bandwagon jumping in an attempt to get a feature tick in
magazine reviews.

On Tue, 18 Oct 2005 11:34:43 +1000, Eric Lindsay
<NOSPAmar2005@ericlindsay.com> wrote:
 
>
>I used padding to the left of my photos, just to keep the text clear of
>them.  That sounds like I may have to rethink.  Or can I get away with
>using margins?

You need padding if you want visible coloured backgrounds on this
padding, or visible borders.  Apart from this, you will probably find
using margins alone to be simpler and more easily ported.

 
>
>I used ems for text, and % for div widths.

% is an oddball in that again you really need to use "no %" or "all %"
(at least for all siblings of the same parent).  There's no problem in
mixing % for a couple of divs to make adjacent columns, then using
pixels inside one of those divs to arrange some images and ems to put a
margin around text in the other div.  The problems arise when you mix
units between siblings - the ratio between well-balanced design of em
and pixel units goes awry when you change text size, or % goes adrift if
you resize the parent.

 
>
>I'm not sure how you manage columns without float left and float right,
>unless I use tables

If you want adjacency and block-level control, you must use either float
or tables.

To really understand float (and in particular, why floated items can
poke out the bottom of the text flow) then you should read this
excellent explanation
http://www.brainjar.com/css/positioning/

>But I would like to avoid [tables] in general layout, if I can.

If you want to fuss over pixel-sizing of adjacent items, tables get the
job done quickly and reliably cross browser in a way that floated divs
can't deliver to IE without enormous effort.


>I'll put Verdana as third choice in my font suggestions.

Either use it first and hope they all have it, or not at all.

> I don't think I want to avoid suggesting a sans-serif font

So use the generic family name sans-serif  (without any quotes) as the
last (or only) choice. Chances are that this will automatically select
the most appropriate sans font for any platform.

There's a reasonable argument that the only useful (and certainly
reliable) values for font-family are serif, sans-serif and monospace --
without useful downloadable fonts, all the family-specific names are
best avoided.