Sent by Paul Novitski on 14 September 2004 18:06
At 12:18 AM 9/14/2004, Francesco wrote:
>Here is some CSS a coworker claims to be superior:
>
>http://www.mentoru.com/site/FRANNY/css_plc.css
>
>and here is some CSS I have presented as being better, and that he has
>publicly called "cryptic" and "fragile" and "a maintenance headache":
>
>http://www.blackcoil.com/css/blackcoil01.css
Francesco,
I agree with my learned colleagues -- I find your stylesheet much easier to
read and understand than your co-worker's, because of the way you've
organized the selectors, the way you've named them, and the way you've used
whitespace and comments to make the stylesheet more humanly readable. Save
me from having to distinguish "mhc" from "mnc" from "mnd" -- and keep
straight their structural meanings -- on a long eye-burning night of coding!
Although many programmers prefer to duplicate properties for each element
like your co-worker has done:
.mhb { color: #FFFF00; }
.mhc { color: #FFFF00; }
.mhd { color: #FFFF00; }
I myself like to group them when doing so makes organizational sense --
first defining the shared properties of a group of related structures
(e.g., h1-h6) and then specifying individual properties that distinguish
them. Done sensibly, I actually find this easier to maintain than defining
everything separately.
This one raised a red flag:
h1.red, h2.red, h3.red, h4.red, h5.red { color: #900; }
A class named "red" (or "bold" or "large") takes one step backward -- it's
embedding presentational decisions in the HTML markup. When -- not if --
the site design and its colors are changed, a class called "red" is going
to seem pretty silly. I'd change it to something semantically meaningful
in the context of the site such as "important" or "error" or "new".
I prefer to stack both selectors and attributes vertically rather than
running them out horizontally, just because vertical lists are much easier
& faster for me to read, eyeball-search, and proofread.
Davezilla said:
>...write out the CSS with single line
>declarations, as Chris mentioned, but then we optimize the code by
>crunching the declarations to a single line each for production (white
>space, tabs and multiple returns add kilobytes).
I respectfully demur. Scripting languages are for humans. I say, do what
you can to make your code readable by people. The difference between:
#banner, #content {width: 750px; margin: 0 auto; clear: both; }
or (Ghu help us):
#banner,#content{width:750px;margin:0 auto;clear:both;}
and
#banner,
#content
{
width: 750px;
margin: 0 auto;
clear: both;
}
is just a few bytes -- and those bytes are far more valuable to me as
formatting than they cost as download. What's a carriage return -- two
bytes? One word? A space is just as large as a tab on disk. Is it OK to
use lots of carriage returns & tabs if you reduce your class names to
cryptic two- & three-letter glyphs? Which type of unreadability do you choose?
If you've got a stylesheet so enormous that the whitespace of formatting it
for human readability adds up to KILOBYTES, perhaps your CSS could use some
streamlining. Anyway, stylesheets are cached, so it's a read-once
issue. My own formatting style will probably seem excessively airy to
some, but I do what I need to do to cater to my ADDled brain and know that
the computers will handle it just fine. Sacrificing readability to save a
few bytes here & there feels very old school to me. I used to feel
compelled to do that in the 80s and proud of saving a kilobyte here &
there. Now that we're in the glorious future of gigahertz processors,
can't we just focus on the sense & readability & elegance of our code and
let the system handle the overhead?
Warm regards,
Paul
______________________________________________________________________
css-discuss [EMAIL-REMOVED]]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
