Re: [WSG] CSS Document layout/structure

[Paul Novitski]

It's fascinating to see so many CSS styling standards.  What makes perfect 
sense to one person can be nonsensical to the next.  Clearly what makes 
styling work for any author is consistency and thoughtful logic -- even if 
that logic is idiosyncratic.

Here's what I do:
Any given page can have up to three stylesheet links (more often one or two):
A. global
  - normalizes defaults across browsers (margin: 0; padding: 0; etc.)
  - styles elements that are common across the site, such as nav menu
B. one css file per class of similar pages.  If a site has only one layout 
template this gets absorbed into global.css.

C. rarely I'll create one css file per page; more often I identify each 
page with a body class or id and style individual pages within its group.

I sequence my rules according to what extent they affect the dimension of 
the current element and the position of other elements on the page:

        clear & float
        display & position & z-index
        width & height
        margin & padding
        borders
        fonts
        text-alignment
        colors & images
The closer to the bottom of the list, the less a rule affects page layout.
On occasion I've tried separating structural & dimensional rules from 
colors & backgrounds to make it easier to change skin while maintaining the 
same layout.  However, in practice I've found that when I'm called upon to 
change colors & images I'm most often also changing the layout, and it's 
made sense for me to keep all the rules for a given page element in one place.

I alphabetize elements (a, code, h1, p) only when defining generic 
standards for the site, but I often and easily overrule alphabetization for 
the sake of cascading hierarchy; for example I always begin with *{}, then 
body{}, before a{}.  I order my own classes & ids according to their 
occurrence in the xhtml or their precedence in the cascade.

Like Dave Elkan I use lots of white-space:
selector
{
        property: value;
        property: value;
}
It's airy but it's ALWAYS readable and easily eyeball-searchable.  I'm a 
firm believer that source code is for humans first; the computer really 
doesn't care.  A few dozen extra carriage returns aren't going to seriously 
bloat my css files, which are cached anyway.

I put a semi-colon after every rule, not omitting the last in a group, 
because I don't want to have to worry about it when I add a new rule to the 
end of the list.

I one-line rules when there's a similar group and the differences are more 
easily perceivable in that format:

body#home  logo { background-color: #600; }
body#who   logo { background-color: #660; }
body#what  logo { background-color: #666; }
body#where logo { background-color: #066; }
I use comments to translate color values:
        border: 1px solid #4682B4;      /* steelblue */
        color: #CCF;    /* calm blue */
Doing this in a consistent way makes it easier to globally replace the hex 
values and their verbal equivalents in one pass [in the absence of CSS7 
global constants or a preprocessor].

Cheers,
Paul
******************************************************
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
******************************************************