Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

CSS Crib Sheet?

November 19, 2003

Alright you Nielsenites you, that didn’t go quite like I expected. It’s probably my fault for calling it ‘Best Practices’ in the first place — what we’re looking to create is more a crib sheet of practical advice, something for reference when a designer gets stuck while using CSS specifically.

“A lot of these ‘best practices’ are just arbitary favouritism for a particular way of working.” - jgraham

I’d tend to agree. While nobody wants a blue, underlined link world, and we’ll be debating for ages the best way to size fonts, this is what I was getting at: “a CSS Best Practice is a one sentence action statement, a ‘thou shalt’ or ‘thou shalt not’ (paraphrased, of course) that highlights a specific issue, be it browser compatibility, code integrity, or whatever else can actually be considered factual (instead of opinion).”

Take a look at my original four examples again — the point is to specifically address things we’ve learned about CSS after working with it for years, that may not be covered in the spec, or pop up when validating. Things like browser compatibility, code integr… you get the idea.

After sifting through the comments, here’s an updated version of my original list. Feel free to add more in the comments, but consider the focus.

When in doubt, validate.
When debugging, you may save yourself a lot of headache by simply validating your code first. Improperly-formed XHTML/CSS will cause many a layout glitch.
Make sure your desired effect actually exists.
There are browser-specific CSS extensions that aren’t in the official spec. If you’re trying to apply filters or scrollbar formatting, you’re working with proprietary code that won’t work in anything but IE. If the validator tells you the code you’re using isn’t defined, chances are it’s proprietary, and won’t work consistently across browsers.
Avoid the Flash of Unstyled Content in IE.
If you rely on @import alone for external style, sooner or later you’ll notice IE ‘flashes’ plain, unformatted HTML briefly before applying CSS. This can be avoided.
Be careful when styling links if you’re using anchors.
If you use a classic anchor in your code (<a name="anchor">) you’ll notice it picks up :hover and :active pseudo-classes. To avoid this, you’ll need to either use id for anchors instead, or style with a slightly more arcane syntax: :link:hover, :link:active
Specify units for non-zero values.
CSS requires you to specify units on all quantities such as fonts, margins and sizes. The behaviour of particular browsers when no sizes are specified should not be relied upon. Zero is zero, however, be it px, em, or anything else. No units are necessary. Example: padding: 0 2px 0 1em;
Test embedded; launch imported.
If you work with a stylesheet embedded in your HTML source, you eliminate any potential caching errors while testing. This is very important when working with Safari, among others. But make sure to move your CSS to an external file, imported with @import or <link> before launching.
Test different font sizes.
Advanced browsers like Mozilla and Opera allow you to resize text no matter which unit you use. Some users will definitely have a larger or smaller default than you; try to accomodate as large a range as possible.
Remember “LoVe/HAte” linking.
When specifying link pseudo-classes, always do so in this order: Link, Visited, Hover, Active. Any other order won’t work consistently.
Build and test your CSS in the most advanced browser available before testing in others, not after.
If you build a site testing in a broken browser, your code begins relying on the broken rendering of that browser. When it comes time to test in a more standards-compliant browser, you will be frustrated when that browser renders it improperly. Instead, start from perfection and then hack for the less able browsers. Your code will be more standards-compliant from the start, and you won’t have to hack as much to support other browsers. Today, this means Mozilla, Safari, or Opera.
Don’t use quotation marks around paths/URLs.
When setting a background image, or loading in an imported file, resist the urge to surround the path with quote marks. They’re not necessary, and IE5/Mac will choke.
Try to avoid applying padding/borders and a fixed width to an element.
IE5 gets the box model wrong, which really makes a mess of things. There are ways around this, but it’s best to side-step the issue by applying the padding to the parent element instead of the child that gets a fixed-width.
Combine selectors.
Keeping your CSS light is important to minimize download times; as much as possible, group selectors, rely on inheritance, and reduce redundancy by using shorthand.

As well, there were some notable theory items that don’t particularily apply to the functionality side of things, but probably should be mentioned:

Organize your CSS file
Make sure to comment blocks of CSS appropriately, group like-selectors, and establish a consistent naming convention, white space formatting (recommendation: spaces instead of tabs for cross-platform considerations), and property order.
Name classes/IDs based on function, not appearance.
If you create a .smallblue class, and later get a request to change the text to large and red, the class stops making any form of sense. Instead use descriptive classes like .copyright and .pullquote.
Consider accessibility when using image replacement
Classic FIR has known problems in screenreaders, and for those who have turned off images. Alternatives exist; use discriminately.

And finally, there were a few points I want clarification on before adding: is using a number at the beginning of an ID just invalid, or does it actually cause rendering problems? And this one — “Avoid horizontal margins and padding on floated elements, IE tends to render them incorrectly” — yeah? Sounds right based on experience, but I don’t have supporting documentation on hand.

Reader Comments

Craig says:
November 19, 01h

In classes, though, numbers and special characters are allowed. So the following is valid (X)HTML:

<p id=”a123color”>Something</p>
<p class=”123color”>Something</p>
<p class=”.&copy;color”>Something</p>

But to make it valid CSS, you have to use the Unicode escape character for the CSS selector with the special character, and you are supposed to escape the the first digit before the class, something like:

#a123color { color: red; }
.\ 123color { color: red; }
.\0000A9right { color: red; }

That being said, neither Mozilla or Opera will follow the last two rules. IE will only follow the first two (it will also incorrectly parse #123color).

November 19, 01h

“…is using a number at the beginning of an ID just invalid, or does it actually cause rendering problems?”

Personally, I don’t care. Even if it doesn’t cause rendering problems in all browsers in existence today, that doesn’t mean it won’t do so tomorrow. Just look at how quickly KHTML went from being the rendering engine for an obscure browser (Konqueror), to a multi-platform embeddable rendering engine used by Konqueror, Safari and Omniweb. What’s around the corner? Will it have bug-for-bug compatibility with everything else out there? Do _you_ want to rely on that?

Here’s another few for the list:

When debugging a layout, use background colours or borders to clarify the exact position and dimensions of each box.

Don’t forget that floating elements will not affect the size of the parent element. Use a cleared child element at the end of the parent element if this is a problem.

When asking for help debugging something, please ensure you have valid code. You can’t waste a validator’s time. You can waste a human’s time.

Funkatron says:
November 19, 02h

Thank you for this list and thanks for the floating elements thing, Jim. I was having that same problem and didn’t know what the heck was going on!

Adam Rice says:
November 19, 02h

If your client wants pixel-perfect everything, post GIFs.

Someone else beat me to the punch, but yes, IDs can begin with digits in XHTML. Not in HTML4.

As to the question of “why validate?” Well, other than giving you a smugly superior feeling, your pages render more quickly and more predictably. I’ve found the difference is noticeable (not huge, but noticeable) even on lightweight pages. Most browsers have a “quirks mode” that they enter when the parser chokes on a page. This forces it to try to lay out the page another time and take edumacated guesses at what the page author intended (admittedly, this assumes the browser’s parser doesn’t have any quirks of its own…). The process of getting a page to validate can help you uncover problems you may have missed, anyhow, so in that respect, it can be a helpful exercise.

Not all my pages validate, but I’m working on it.

Dris says:
November 19, 03h

“Test embedded, launch imported.”

Actually, I’ve found that Safari consistently reloads the CSS file when reloading, at least in my case with a ed stylesheet containing @imports. IE/Mac, however, consistently does not.

I like the LoVe/HAte memory trick. Very nice.

Lach says:
November 19, 05h

“(recommendation: spaces instead of tabs for cross-platform considerations)”

Does this really cause cross-platform compatibility? Only I’ve never heard of such problems before. Personally, I think it’s ludicrous to use spaces instead of tabs. It increases file sizes, and is a lot less flexible to individual reader / writers’ preferences.

I don’t know of any half decent editor that won’t let you specify the amount of spaces each tab should be, so it can work at the right width for you and someone else, even when you both use different widths. However, I know of quite a few editors that can’t change all the leading spaces around so easily.

Lenny says:
November 19, 06h

I suppose I’m out of the loop. In the LoVe/HAte thing, why should :hover be defined before :active?

Define font-family and margins for the page in a rule for html and body for Opera.

benry says:
November 19, 08h

Eric Meyer will tell you that links should be in the following order in your stylesheet (as will Joe Clark):


:link, :visited, :hover, :focus, :active

José Jeria says:
November 19, 11h

If I am not mistaken, early Opera 7 versions also flashes with unstyled page before it applies the css. I have not been abled to reproduce this with the latest 7.22 though.

Kristine says:
November 19, 11h

Since you mentioned remembering LoVe/HAte for link order, another good reminder is TRouBLe for the shorthand of border/etc. properties: Top Right Bottom Left. :)

Name your stylesheets consistantly – if you put sitename.css in the images subdirectory of every site you design, it’ll be easy to reference in new pages without thinking.

HTML editors with syntax highlighting (or better yet, a CSS editor like TopStyle) can really help if you are still learning where semicolons and curly brackets should be – you’ll be more likely to see an error faster than if you were using a text editor.

Eric says:
November 19, 12h

If your client wants pixel perfect support in NS4, double your budget and be prepared to walk. :)

November 19, 12h

“is using a number at the beginning of an ID just invalid, or does it actually cause rendering problems?”

I have had a page break mysteriously in MSIE (probably version 5). In the end the problem turned out to be “id”s named with numbers at the beginning. Most of the time MSIE will grok such “id”s, but not always. So better be safe than sorry.

Craig says:
November 19, 12h

Numbers at the start of an ID (and NAME) are, in fact, invalid. They are also case sensitive.

Good suggestions, BTW.

Michael says:
November 20, 01h

“you can apply said title attribute to elements using it.”

That’s ingenious. It would be nice to use for something like a credit to the designer of a logo.

On topic: This is hard. Most of the documented stuff, if it is specific, is not up-to-date. I had a good trawl through this rather lengthy list:

Full and good as it is many of the links refer to problems and ways of working that are no longer current.

Tim says:
November 20, 02h

“Most browsers have a “quirks mode” that they enter when the parser chokes on a page.”

AFAIK, quirks mode is not triggered by valid or invalid code, but rather by the doctype that you use.

November 20, 02h

Perhaps i’m just an amateur that pursues web design as a hobby, but I run my church’s website, and I found two of your original 4 pointers (not using quotes around an image location in CSS, and the IE5 padding/absolute width snag) to be **EXTREMELY** helpful. The issue with using quotes around a root-relative image location I figured out on my own, but had I been alerted to the box-model hack earlier, it would have saved me months of bemusement and frustration. Thank you.

Dave A says:
November 20, 02h

I’d love a whole section of the CSS crib sheet to be devoted to web forms. I haven’t found many good references for marking up and styling accessible web forms.

jgraham says:
November 20, 03h

I think the main advice with styling forms is “don’t”. In general it’s not defined by the spec (I think that form controls are supposed to be replaced elements, like images. However the style rules for images and forms generally work differently). There are also significant platform issues. For example OSX buttons aren’t designed to butt up against each other in the same way that windows controls are. This can break layouts. Other controls are also intrinsically difficult to style. How would one style a select, for example. Form controls, in general, aren’t a problem that is in the domain of CSS; to work with them properly you need something more sophisticated like Mozilla’s XBL.

Obviously some things will work. For example sizes of text areas will probably play nicely across different platforms and browsers. I’d guess you’d be OK with positioning as well and maybe even things like background colour (although, without reading the spec, I’d guess that most background colour implementations are wrong per the spec). But don’t rely on form elements to hold together a layout e.g. by having a specific size. Care to write that as a crib note?

AndyT says:
November 20, 03h

“When specifying elements such as margin: 0 0 0 0, remember the order with “TRouBLe” - Top, Right, Bottom Left.”

Can you not do just
margin: 0;
or is that not allowed anymore?

Also, how come css images have no alt text variation? Isn’t this a kind of hindsight considering that IMG tags must have alt text defined for it to validate.
In this case, wouldn’t IMG tags be better suited for images than the css version, as alt text is defined for no images browsers and it is, in a sense, content of a sort?

Adam Rice says:
November 20, 04h

I think you’re right after all. My goof. However, I have noticed that Safari (at least) does render valid pages faster than in-.

Dave A–
There was a good intro on styling forms at ALA:
This has nothing to do with goofy stuff like making your buttons pink, of course…

Funkatron says:
November 20, 04h

I have a question: After you have a well-marked (X)HTML page and you begin coding in CSS, do you begin with type styling and colors or overall layout??

Tim says:
November 20, 04h

“Also, how come css images have no alt text variation?”

Because they are presentational and thus have no meaning. The meaning is derived from the (X)HTML.

Lach says:
November 20, 05h

Or, if you don’t want all the crufty markup of the ALA method: [insert standard self-plug disclaimer here].

Paul G says:
November 20, 06h

How about these two:

1. Provide a fall-back list, including either “serif” or “sans-serif” for any font-family declarations. Make sure that your list is consistent with your first choice, i.e., if your first choice font is sans-serif, all the fallback fonts should be sans-serif as well.

2. Use font-size-adjust to maintain a consistent look when users don’t have your first choice font.

Motekye says:
November 20, 06h

:: #49 I disagree with a few of Motekye?s items:

:: - For images and objects: Set the height and width of objects with CSS, rather than width and height attributes.
:: That doesn?t make any sense. The width/height of those elements is usually important, irregardless of CSS or not and they often need to maintain those dimensions apart from the CSS.

Often when I change site styles, more than the CSS needs changing. I like to leave my markup alone over re-designs, but often images need to be re-sized to fit the new layout. Thus, I specify the size in the CSS and with no style, the image will adopt it?s normal size.

:: - Code for CSS scroll-bars should be kept in a different file as to prevent the main stylesheet from failing validator checks.
:: I?m probably going to get jumped on for this one, but what?s it matter if a style sheet is valid? So long as browsers ignore styles they don?t know you are good to go. People?s obsession with validity is puzzling to me (unless you need to send your XHTML through a parser, then that?s a different story).

Though validation has few if any practical applications, it says a lot about a designers credibility and integrity when they uphold to the standards presented by the W3C. Sure, depreciated code works, but it?s not optimal. Major validation errors can mean that your code will render improperly when a browser upgrades it?s web-standards support. It?s just a good idea to follow these guidelines. Also, I like the little yellow button!

:: - When an element appears only once in a document, use an ID instead of a class.
:: Not necessarily a good idea either. If you are positive that that element is only going to appear at most once on every page, then yea, go for it. But often times you don?t always know.

It?s pretty simple to predict that you will not need to use an element elsewhere. #nav would be a likely id candidate, unless you have navigation menus on the top and bottom / left and right of your site. footers, logos on layers, etc.. are all excellent uses of IDs.

:: - Wrap the contents of the body in a div or span so if you decide to move to a fixed-width or contained style, it will be MUCH easier.
:: That?s a good one, for now. Since most modern browsers will allow you to style the BODY tag apart from the HTML tag, that is becoming less of a must.

I have never been able to get styles on the html tag to work on IE 4 or Opera 6. I nest for safety reasons.

:: - When specifying titles, use h1, h2, h3, etc.. instead of divs with the class “title”. Use paragraph blocks or blockquotes instead of text-containing divs.
:: Hate to be picky, but that falls under the category or HTML practices, not necessarily CSS.

The two often share jurisdiction. I just noticed that a lot of new CSS designers are blinded from proper html structure by the lure of styling a proverbial blank slate ( the div ) and thought I?d tie it in.

:: - Floated elements should appear before non-floated elements in the page source. Use floats for layout whenever possible. Use clear on footer elements, even if the floated block does not reach them.
:: That?s a bad practice because you should apply your CSS after you have the HTML and not have to put it the other way around.

For modest styling, I agree. But when a design relies on CSS, it?s better to change a bit of html than go through a CSS nightmare. I placed the side-bars before my content on my old blog for this purpose, it has not hurt the layout in any way for non-float type designs.

:: - Avoid using alpha-layer transparency, drop-down menus and other IE only CSS.
:: I think it is perfectly acceptable to use browser-specific CSS, be it IE scrollbars, Mozilla border-radius, etc. Use what you have available if they fit the situation. And Moz does have support for alpha transparencies. (Not sure how drop-down menus are IE-only CSS.)

Hmm.. I see your point. However, browser only CSS should be avoided when a major feature relies on it. I have seen IE-only drop down menus before, IE-only for lots of things. Something as crucial as navigation should not be left to chance.

:: Sorry to be the devil?s advocate.

Don?t apologize, it?s people like that who keep web designers on their toes. :)

:: #51 Floats always seems to require so much more from me when doing layouts, especially when it comes to IE.

I have never had any float crisis? with IE aside from horizontal padding/margins, I just find them to be universally acceptable practice. They are they only method I know of for doing columns on a fixed-width, centered design. Floats are also good for sizeable designs - I don?t know why everyone bad-mouths them.

Anne says:
November 20, 07h

Responding to AndyT

margin:0; is perfectly valid. It will be translated by the browser into: margin:0 0 0 0; to go on:
margin:0 1px; => margin:0 1px 0 1px;
margin:0 1px 2px; => margin:0 1px 2px 1px;

Some images shouln’t have a alt text. If you are embedding such an image using HTML you will have to specify alt=”“.

About id attributes. This works and AFAIK, it is valid too:

<style type="text/css">

<h1 id="&#x34;">Blah</h1>

AndyT says:
November 20, 07h

“Because they are presentational and thus have no meaning. The meaning is derived from the (X)HTML.”

That makes sense, but images are not always presentational. Like some of the images in CSS ZenGarden, they are really content (or replacement of the text variation) such as in headings. In this case, an alternate text should be provided much the same way as the IMG tag for the same reasons.

I think the problem is that some images are part content/part presentation. In the examples shown in CSS ZenGarden, the text would never change, but the style in which the text are represented would.

Andy T

PS I apologise if this isn’t a place for these types of discussions considering the topic, and would happily be directed to the appropriate place.

Anne says:
November 20, 07h

To correct me previous comment (18), the validator claims it is invalid. I thought I have read about it somewhere. I hope I find that resource again soon!

Michael says:
November 20, 08h

“PS I … would happily be directed to the appropriate place.”

It probably is a bit OT, Andy. You might try:

You may be right to say:

“I think the problem is that some images are part content/part presentation.”

But I guess that just means that you can’t have a definite answer and have to make a judgment in each case. If it really is “just a backdrop” then I guess it is of no interest to the blind - or to users of graphical browsers who have images switched off. In any case, “alt” is more a “placeholder” and if there is something further significant to be said “title” is the place to do it:

… unless you already have your description on the page, which would make “title” a redundant duplication.

Sorry, I’m well OT, too. Try here:

Dave S. says:
November 20, 10h

Just to further the off-topicness, using FIR, you can apply said title attribute to elements using it, ya know. No one has ever told me how well that works with screenreaders, but it’s one possibility to supplant ALT text…

Andy - in a lot of cases, you’ll want to use an IMG instead of FIR for images that can be considered content. We like FIR around here because it opens up a lot of possibilities for alternate styling, as the Zen Garden demonstrates - but that doesn’t mean it’s appropriate in every instance.

November 20, 10h

“recommendation: spaces instead of tabs” and “Keeping your CSS light is important to minimize download times” seems to pull in different directions. Replacing a tab character with 8 space characters doesn’t exactly help minimise download time…

Rod says:
November 21, 03h

#28: “[D]o you begin with type styling and colors or overall layout?”

What do _you_ find easy? What do you want to do and why?

If you’re re-using the layout with different type-styles and colors (and neither is more tied in to what you’re doing than the other) -

- maybe yes. If not, maybe no. Maybe the whole thing came to you in a dream, and there the colors struck you more than anything.

November 21, 04h

The Monkey wrote: “Having helped family member get online and surfing, it still surprises me how the simplest things can throw them. I had a friend hit a web portal about antiques, and while surfing got stuck on a page. There were easily more than ten links within the body copy, but the page didn’t have any menu structure. They’d styled the links without an underline, and used a colour similar, but a few shades lighter, than the body copy. These were completely ignored. I had to physically show my friend that they were links.”

Surely it is too much for designers to dumb down their sites to the lowest possible level? Cars don’t have labels showing what each pedal does - the driver has to LEARN. So everyone using a website has to do the same. Over time they will learn how links work, learn how forms work. We were all beginners at one point, but we all figured it out, right?

Yes, don’t put in confusing styles, like underlined text that isn’t a link next to an underlined link.

I heard of a true story where an old man was shown how to use the web. He wanted to search for topics related to history. Suddenly he pointed to the browser toolbar and with delight. There was a “History” button!

Computers are so complex you never stop learning. I’m still finding things a browser can do that I didn’t know was possible. The same goes for Windows. But do we really want annoying tooltips on everything, even the Start menu? It says “Click here to begin” when you hover over it. But what if I want to shut down the computer? I still go to the Start button. So the tooltip is meaningless.

Adam Rice wrote: “Someone else beat me to the punch, but yes, IDs can begin with digits in XHTML. Not in HTML4.”

I think it’s a matter of whether they are valid in CSS or not, not HTML. In Eric Meyer’s CSS2 Test Suite, he declares:

“ID selectors cannot begin with digits in CSS1”.

See the test here:

November 21, 08h


Is it okay to use #bbc rather than #bbcbbc? Is this acceptible in all browsers.

Plus, why is it *not* okay to use names such as “red”?

Thanks in advance.

Dris says:
November 21, 09h

Yes, the shorthand for websafe colors is there to be used, and we all know that a few saved bytes can mean a lot on a big website. I’ve yet to come across a fairly modern browser that screws up on this.

Using “red” and the others is safe in basic designs that deal only with minor styling of content. If the color isn’t critical, go for it, but make sure the color is actually one of the colors specified in the spec. However, if you demand accuracy for your colors (especially between browser-rendered color and color in images), keywords aren’t the way to go. Browsers don’t seem to agree on what they are, especially gray. Try it in a number of browsers, and you’ll end up the same number of different shades.

Then again, browsers always seem to find differences in colors that should be the same, but you’re better off not using keywords with only relative meaning.

November 22, 06h

[ Is it okay to use #bbc rather than #bbcbbc? Is this acceptible in all browsers. ]

#bbc is #bbbbcc, isn’t it ?

November 22, 06h

“Surely it is too much for designers to dumb down their sites to the lowest possible level? Cars don’t have labels showing what each pedal does - the driver has to LEARN.”

I think the problem is that when you run into pages that are difficult for even experienced users to navigate. If it takes me more than a few seconds to figure out how to navigate a site, then odds are that their design is overly esoteric. Sometimes the conformity isn’t as much for the beginners that don’t know what they’re looking for as it is for the advanced users that do know what they’re looking for, and also know that certain things shouldn’t be done.

November 22, 07h


> Cars don’t have labels showing what each pedal does - the driver has to LEARN.

Pedals work the same way across multiple cars. The problem with disguising links is that what used to be a consistent interface across every site (blue underlined text == link) is now a mess of whatever a site designer sees fit to do.

To follow up your analogy, would you think that it was a good idea for every car manufacturer to have a different interface for their cars? So, when driving one car, the left-hand pedal would be the accelerator, and when driving another car, the left-hand pedal would be the brake? After all, can’t the driver just LEARN?

> I think it’s a matter of whether [IDs beginning with digits] are valid in CSS or not, not HTML.

No, IDs are part of HTML, not CSS. Quoting Eric Meyer is useless - it’s the relevent specifications you need to quote.

In HTML 4.01, the id attribute is of type NAME, and “NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens (“-“), underscores (“_”), colons (“:”), and periods (“.”).”


Yes, shorthand “doubles up” the digits, so #bbc is equivelant to #bbbbcc. The only browser I know of that got this wrong was an ancient version of Konqueror due to a bug in Qt.

jgraham says:
November 23, 03h

Moreover, if you find somone who doesn’t recognise links unless they’re blue and underlined, there are browser settings that will let you enforce just that, across all pages. They’re called Cascading Style Sheets for a reason.

Michael says:
November 23, 04h

Chris said, “Cars don’t have labels showing what each pedal does - the driver has to LEARN.”

I agree links don’t have to be either (a) blue or (b) underlined. But the analogy isn’t good, and this unfortunately gives Jim a foothold.

Variation in the indication of links is acceptable *and the spec allows it and makes it possible*. That is the starting point. Better analogies for fending of the puritans might make reference to learning to recognize faces, or learning to read. These are far more complex tasks, than recognizing a link.

The beautiful new website for a certain browser is a case in point. The links are not blue nor are they underlined. They use several different colours. But I have no problem in finding them.

Above Dave with consummate sense says, “While nobody wants a blue, underlined link world…”

In effect this means “nobody [of any sense] wants a blue, underlined link world”.

Dave S. says:
November 23, 10h

Perhaps, Michael, more specifically I meant “nobody [with any sense of aesthetic] wants a blue, underlined link world…”

Jakob Nielsen - - is a big proponent of not screwing with link colours, so some will go along with that. I think a few good points have been made above – you really don’t need blue links as long as your links are clearly indicated. #333 links with #000 text is just bad design; no need to penalize the rest of us because some insist on doing that.

At the same time, users have to meet the designer halfway. The human brain is more adaptive than some usability advocates seem to give credit for; once a user has wrapped his or her mind around the hyperlink paradigm, the colour of links becomes irrelevant as long as they’re clearly links.

Jeff Walden says:
November 24, 01h

Another alternative for the syntax, which I’ve been using for a while (the selectors are CSS2, but they’re part of the minimal amount implemented by about every recent browser):

a:link { /** style **/ }
a:visited { /** style **/ }
a[href]:hover { /** style **/ }
a[href]:active { /** style **/ }

Michael Havard says:
November 24, 08h

Here’s something I don’t understand about some of the arguments being posed: Many people are questioning whether numbers work (and are valid) at the beginning of a class or id, but I haven’t seen anyone suggest WHY you would want to start you’re class or ID with a number.

I would assume that it might be some kind of generated interface. Even if that were the case you could just as easily start the generation out with a character instead of a number.

So far as I’ve seen the move is toward better semantic identification of information not abstraction. So it would be better to see “subFolderOne” vs. “1sf” or “/_s_1-f” (which is another point - why put special characters in your id/class names?)

I do like some of the ideas about seperating out css files into valid files, hacks, and proprietary calls. I think from a maintenance perspective and from a dynamic content generation point of view it’s much more robust. For example if I know at the server level that I’m serving to Mozilla I can just not send the hack.css and ie.css files down as they’re not necessary. Or if the hack.css no longer becomes necessary I can remove it and the links to it without having to dig around in my site.css code and weed the hacks out. Plus you might get some bandwidth savings from caching when you need to change site.css but nothing from the hack.css/ie.css files.

Michael Havard says:
November 24, 08h

One suggestion I have is that if you are going to change major elements like link behavior and provide a rich UI, you should also provide some basic help for new users. Create a simple help page that explains the conventions you’ve used and why they’re different. Something someone can read quickly and then get on with business.

Tim says:
November 25, 01h

“Quoting Eric Meyer is useless - it’s the relevent specifications you need to quote.”

Um, Eric virtually *wrote* the spec - he’s one of the most eloquent advocates of CSS and Web Standards and, along with Zeldman, has done more than most to advance CSS adoption.

Specs are for browser makers, not developers. We need people like Eric to explain it in real-world terms.

Dave S. says:
November 25, 10h

The Crib Sheet has moved to a permanent archive, and a new thread has been established for continuing discussion. Please add any new suggestions there: