Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

CSS Best Practices

November 17, 2003

I’ve been thinking about how to put this together for a while, so I think I’ll open it up to everyone for contributions, then build an actual resource out of it somehow.

Here’s the idea: 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). It’s followed by a paragraph that goes more in depth about why or why not someone would want to follow the action, with links to further reading. This is the stuff that, if you know it ahead of time, makes your design process much less of a headache.

The final resource would be a single-page collection of learned knowledge that might otherwise be spread out too much to be useful. Consider it a crib sheet for designing with CSS, one page that’s full of valuable guidelines.

Here are some of the ones I’ve started with:

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.

That’s just a start. There are a ton at the back of my mind, but I’m having trouble fishing them out. This is one of those instances where you need to be doing it at the time to remember all the specifics. Add your own in the comments.

Reader Comments

Dave S. says:
November 17, 01h

Also: has this been done elsewhere? I haven’t seen anything quite like it; the css-discuss Wiki - - seems to be a far more in-depth version of the same, but it’s too weighty. I’m looking for something simple, snappy, and light in detail. Just the facts, ma’am.

Lenny says:
November 17, 02h

If using Fahrner image replacement ( set media to “screen, tv, projection” so voice browsers and printers show something useful.

Pix says:
November 17, 02h

If your CSS file is long, organize similar rules together and use comments before each section. This may help you keep track of things for future redesigns/updates.

Sebastian says:
November 17, 02h

Here’s one:

Never name your classes “arial15centered” or “smallbluefont”.

One of the most important benefits of CSS is being able
to change the look without having to change the HTML.

So what will you do when your boss comes and tells you
he doesn’t like his titles centered? or that he wants the
fineprint in red instead of blue? If your clases had been
named “title” and “fineprint” your HTML document
wouldn’t have worked as is.

Use functional names for your classes, avoid words that
describe how they look.

Believe me… I’ve seen such aberrations more often than I thought possible.

November 17, 02h

Here are a few contributions:

1. Use :link and :visited instead of “a” to set link styles. Use :link:hover and :visited:hover to set link rollover styles.

Details and rationale:

2. Use image replacement methods that are compatible with non-graphical browsers (should include explanations of best image replacement methods and potential pitfalls).

November 17, 02h

3. Test pages with different fonts and sizes. Prefer relative sizes and em units, so that layouts scale to fit larger and smaller fonts.

A “best practices” document should also include preferred methods of setting font sizes, though this is such a quagmire that I’m not sure what the best practice might be…

November 17, 02h

Sorry, I keep thinking of more.

4. Place your CSS rules in an external stylesheet, so that they do not need to be downloaded again each time a new page is loaded.

November 17, 02h

When you declare a font-family, include at least one semi-ubiquitous option for each major OS (Windows, Mac OS, Unix), and always end with one of the generic font keywords (serif, sans-serif, etc.)

Dave S. says:
November 17, 02h

Matt - point 1 is perfect, but 2 and 3 wouldn’t fit. They’re too mired in opinion, second-guessing, and statistics. I’m looking more for quick shots that make life easy, over going into the philosophical discussions that plague font sizing and image replacement.

Eric says:
November 17, 02h

Always define attributes alphabetically. It may seem nice to put your left/right and top/bottom together, but it makes your CSS more readable for other people and it severely reduces the chance of duplicating property definitions.

November 17, 02h

The best practice for font-size, in my opinion, is to use what your readers have their browsers configured for. I guess loads of people will disagree with me on that one though, as it seems there’s some kind of a phobia regarding 1em/100% font sizes with designers.


- Don’t make assumptions. Don’t assume a certain canvas width, don’t assume Javascript is enabled, don’t assume the user is using a certain font size, and so on. Making your design revolve around common configurations isn’t bad, but forgetting that visitors have unusual configurations from time to time leads to breakage.

- Use decent markup. Try and stay away from <span class=”important”> and so on, when <em> would do nicely.

November 17, 02h

Matt said:

“Use :link and :visited instead of “a” to set link styles. Use :link:hover and :visited:hover to set link rollover styles.”

I wasn’t aware that these were valid pseudo classes? Isn’t it easier to just used a:link, a:visited, a:hover and a:active? As long as you specify them in that order then the hover class will work on visited links too.

My tip would be, if you need to use an IE.x box model hack, the High-Pass filter method is the most elegant. Use only one link element to link to a basic stylesheet for old browsers and one import rule to import another main stylesheet. In this main stylesheet, use the high pass filter to import your’re separate ie5 and normal stylesheet.


1) Reduces the number of link and @imports on your pages.

2) Keeps all “hacks” (ie IE5 only code) separate so it can be easily removed at a later date

3) Solves the FOUC bug.

November 17, 02h

eric, keeping everything alphabetical might appear nice, but makes it a lot harder to see the various inheritance issues etc when it’s not ordered in a semi-logical, document-structure related way…

Eric says:
November 17, 03h

Patrick, I mean attributes, not classes. e.g.

.className {
border:1px solid black;

instead of

.className {
border:1px solid black;

As far as ordering elements and IDs, I have a system I use but it’s just a habit, nothing I would submit for a best practice.

jgraham says:
November 17, 03h

How about:

CSS isn’t a magic bullet
It is still possible to create slow, inaccessble pages that are a pain to maintain when you use CSS to style them. Think carefully about the needs of your audience and remember that most people don’t have the same computer setup that you do, so strive to avoid designs that require a specific screen resolution, excellent vision, or certian fonts.

If that’s too cynical then:

Remember to specify units
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.

Don’t specify font heights in pixels
Font heights in pixels prevent Internet Explorer users from reasizing your text, which may make your site unusable for many visitors. Use a different units system for text instead, for example % or em.

MikeyC says:
November 17, 03h

When setting an element’s ‘color’ remember to set a ‘background-color’ as well.

MikeyC says:
November 17, 03h

Although it is tempting to use CSS to make a hyperlink look like anything BUT a hyperlink… don’t go overboard!

November 17, 04h

Luke: “Isn’t it easier to just used a:link, a:visited, a:hover and a:active?”

This causes problems if you have something like this in your HTML:

<a name=”misc”>Miscellaneous</a>

In Mozilla and other modern browsers, this will be selected by a:hover and a:active even though it is not a link. If you don’t want this, then you need to include the :link and :visited pseudo-selectors.

These and other pitfalls are explained in detail at the page I linked to previously:

ACJ says:
November 17, 04h

When in doubt, hide the StyleSheet(s) from Netscape 4.x.

The major problem with the NN4.x generation is that it reads some CSS, ignores other, and… reads some the wrong way.
With older browsers like Mosaic, Netscape >3.x, etc. you don’t have to worry about how it reads your StyleSheet because it won’t even try.
NN4.x, however, will read the StyleSheet, but usually not correctly.
Provide special styles for this specific browser family, or simply make it ignore the entire StyleSheet or the parts of it that cause problems.
An easy way of hiding and entire StyleSheet for NN4.x is my adding media=”all” to the link reference.
A specific part of a StyleSheet can be hidden by closing it in (and by that excluding for media that don’t understand) with @media all {}.


Adam Rice says:
November 17, 05h

The “rely on inheritance” rule is an important one, and frequently overlooked in my experience. People often add redundant classes to their HTML, such as {…}
#bar p {…}
would serve better. It does take a little more mental juggling, though, and you can get into tricky context situations.

November 17, 05h

Hyperlinks should always be underlined unless they are in a group of clearly-defined navigation links.

sergio says:
November 17, 06h

- Favor Relative positioning over Absolute.

It’s tempting to place every element in your design using absolute positioning, but when you add new elemets between two absolutely positioned objects they will ignore the flow.

If you Absolutely must (pun intended), try to stick with Absolutely positioned top-level “containers” with Relatively positioned elements inside them. That way, when you insert new elements in there the other elements in the container will flow normally (usually to the right or bottom of new elements).

With some editorial uh… editing, of course.

Stephen says:
November 17, 08h

Sorry, but I have to disagree Sergio.

You can create amazing effects by placing an absolute positioned block inside a relative block with left and top set to 0. I think you are forgetting that an absolute or relative block resets any sibling’s origin to the parent block’s top left corner.

So don’t limit positioning without giving some serious thought to it.

And I was going to say what MikeyC said regarding backgrounds and colors but he beat me to it… (although what he said should have been said long ago.)

I would propose that when creating a style sheet, you should always start with basic elements such as h1, p, ul, etc. It’s a simple start, any author would recognize those rules (which helps user style sheets and therefore accessability), , and it makes sure you keep the inheritance simplified. This is something I learned recently making my latest design much simpler.

[Dave, I love this idea! A simple guideline which can lead to advanced CSS techniques, incouraging both veteran and rookie authors to share and learn off one another… Why reinvent the wheel, right?]

November 17, 09h

Hello. I’m not sure if this fits into the “best practices” thing, as it might be specific, but

* Hiding CSS from NN4 _and_ IE4 should be a best practice. IE4 is often ignored both in testing and in hiding.
Either you take care of it properly if the project allows, or you hide from both.

* Hiding inline CSS on XHTML. I think Mr. Clover’s Evil Mangled Comments Hack is a must under this condition.

sergio says:
November 17, 09h

Stephen: I was referring more to the tendency to overuse the absolute positioning as the swiss army knife of layout-ing. I didn’t mean to dismiss absolute layouts as a tool. But I often see designs that would work perfectly fine with relative positioning but use absolute (perhaps out of laziness). Guess I didn’t explain it well.

Stephen says:
November 17, 10h

I’m sorry Sergio, I think I came off a bit too harsh…

I completely agree with you on your point that absolute positioning can be hazardous to any design when the content has not been carefully considered (what will change, what won’t change, etc)… In the long run relative positioning is definately more reliable.

But that rule cannot be guaranteed. Many designs (such as my site’s menu system) could not function without nested absolute positioning. So while I agree with you, its based on too much opinion for this instance.

Doug Bowman explains it better than I ever could (he gave me the idea!):

November 18, 01h

Agree with Roger Johansson. A best practice should include an indenting style, so when you get to someone else’s css you find your way easily.
I like the following, borrowed from Bowman:

- - - - - - - - - - - - - - - - - - - - */
selector {
–TAB– color: #FFFFFF;
–TAB– }

Also agree with making all css internal (that’s why I use - - - - instead of —– so it will validate)

Matthew Farrand says:
November 18, 02h

1. Use comments and use them well

2. Document your CSS

3. Order your rules and selectors consistently

These days stylesheets can be over 500 lines long and even if you are the only one working on your site’s CSS, revisiting an uncommented stylesheet can be a nightmare. Just where are the rules for the navbar?

I find judicious use of comments to mark the beginning and end of each section of a stylesheet to be a godsend. Through bitter experience I have found that not writing down the order in which rules appear can waste countless hours at just the wrong time.

Usually I start with general styling of HTML tags, continue with links, lists and forms and then follow this with contextual rules for each div in the page, done in the order in which it appears in the HTML. I then finish with classes and miscellaneous items. I don’t know if this is the best way but at least it’s consistent.

Maurício Silva says:
November 18, 02h

I’d like say: Many thanks for this Article and all comments. I’ve printed it and I’ll spend all the time that will be required for “drink” - a very strong portuguese expression for learn :-) - the CSS lessons, tips and tricks on it. And sure, I’ll visit all posted links.
Thanks and thanks!

November 18, 02h

To elaborate on the original #4, on combining selectors and keeping the CSS “light”:

Write valid, structural markup (HTML, XHTML) and try to select on the HTML as much as possible before adding classes and IDs to the markup. This will increase an understanding of inheritance and provide greater flexibility in future revisions.

Isofarro says:
November 18, 03h

Start with valid and well-structured HTML.

benry says:
November 18, 04h

My thoughts:

- Use specific IDs (i.e. div#idname) where possible. This isn’t required for elements and classes
- Add comments where appropriate, it will help later in the understanding of what you have done.


- List styles in the following order: IDs, elements, classes. Within this list alphabetical unless cascade flow does not allow (i.e. LVHFA)
- Keep a consistent order of properties.

Brian Standish says:
November 18, 04h

“… resist the urge to surround the path with quote marks. They’re not necessary, and IE5/Mac will choke.”

But M$ has killed it. Sure, no reason to choke it but do we know that won’t cause a problem for anything else?

Rob says:
November 18, 07h

Be cautious in what CSS items you group together.

Grouping can make your CSS harder to maintain, especially in situations where you are not the only one that is going to edit a given CSS file. Other people working on the project may not notice that you have grouped an item. I’m not suggesting avoiding grouping all together, but be cautious in what you group. I would suggest not to group distinctly different items together (for instance, headers from different DIVs). Grouping within “sections” is understandable (and probably good practice).

November 18, 07h

Let me refer to an article by Peter Paul Koch which was published on Digital Web some days ago:

P.S. Digital Web seems to be down for me, but I’m pretty sure this is the right URI.

Anne says:
November 18, 07h

Grouping is dangerous:

Jason says:
November 18, 08h

A few simple ones:

1. Do not use underscores in class and id names. Some browsers will choke. See

2. When accessing stylesheets in the head of the document, if you use @import, also add a link rel=. This should eliminate the Flash of Unstyled Content. See

3. Always validate your CSS. See

November 18, 08h

Here are two other suggestions:

Before starting off with creating a *.css file, draw a complete structure of the website, which contains all elements and their interdependencies. This may not be helpful at smaller pages (with less content or easy structure) but is inevitable in bigger redesign projects. Do not start to change/create HTML or CSS before you have such a drawing (using *idunno* Visio or Powerpoint or any none-M$-product ;)

Do NEVER EVER use numeric characters in your classes and element titles. Bad example:

span.tree123 {
… blablabla …

If this leads to an error with some of the browsers, it’s hard zo find the error in a large CSS- file (if you don’t know they’re allergic to numbers).

November 18, 08h

It’s illegal to start an ID with a number.

I know that and still fell in to the trap just yesterday…

November 18, 08h

Oops… just saw that it has been posted. Should have refreshed my browser!!

Jon Plummer says:
November 18, 08h

Most of our sites begin with an overall layout of blocks, correct? Three-column with header or what have you. I have found it very useful to begin my stylesheets with asimple and indented structure that outlines just the layout-related selectors and rules for the template. For example (rules removed for clarity, indents faked badly):

body { }
—- #header { }
——– #logo { }
——– #topBar { }
———— .accessoryNav { }
——– #mainNav { }
——– #subNav { }
——– #wrapper { }
——– #content { }
——– #error { }
———— .contentBlock { }
———— #processNav { }
——– #help { }
—- #footer { }

…to whatever level of specificity you find useful. You might want to put h1 in there, for instance. I then follow this structure with some sort of reasonably ordered set of selectors and rules that happend to be more oriented toward colors, borders, backgrounds, fonts, and the like, as well as highly local layout.

This (putting the general layout at the top, indented) exposes the general HTML structure in the CSS, which helps you visualize the former while you are working in the latter, and also helps to separate your thinking about layout from your thinking about decoration, if you’re into that sort of thing.

Jim says:
November 18, 09h

“Hyperlinks should always be underlined “


What’s the use of text-decoration:none if it’s improper to use it?

In the beginning we had no choice but to underline hyperlinks, now css gives us a few choices. I don’t think the average user is so bad at recognizing a non-underlined link so long as it contrasts enough with the surrounding text.

November 18, 10h

“… resist the urge to surround the path with quote marks. They’re not necessary, and IE5/Mac will choke.”

I haven’t seen IE5/Mac choke when double quotes (aka inch marks or double primes) are used around file paths. Single quotes (aka foot marks or primes) do confuse it though.

November 18, 10h

Jim - people are used to seeing hyperlinked text underlined. It is easy to catch visually and is pretty standard. For decent usability, you should offer people what they expect. Some people prefer using bold text or something else, but that doesn’t come across the same way.

Most of these aren’t “best practices” though. O well. Things like indentation styles should be decided upon on an organization by organization basis.

Motekye says:
November 18, 10h

- For images and objects: Set the height and width of objects with CSS, rather than width and height attributes.

- Code for CSS scroll-bars should be kept in a different file as to prevent the main stylesheet from failing validator checks.

- When an element appears only once in a document, use an ID insteado of a class.

- Use CSS child-node selectors instead of classes on nested elements.

- 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.

- 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.

- Avoid horizontal margins and padding on floated elements, IE tends to render them incorrectly.

- 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.

- Always end a list of fonts with a generic class.

- Avoid using alpha-layer transparency, drop-down menus and other IE only CSS.

That’s about all I can think of, right now.

Michael says:
November 18, 10h

“The best practice for font-size, in my opinion, is to use what your readers have their browsers configured for. I guess loads of people will disagree with me on that one though, as it seems there’s some kind of a phobia regarding 1em/100% font sizes with designers.”

Sure would. This would imply that I would want the *same* font size on every document I encounter on the Web. No way.

Also, the default in my main browser (Safari) is 16px Times at 96dpi. That seems about right. But what if the designer chooses, say, Verdana? That’s a very chunky font which looks quite different at 16px.

The assumption being made is that my (non-existent) preference here is independent of typography and independent of the design. I can’t see that that’s true.

Notice I can’t specify a “preference” for every font with that control. But that’s no problem. The default I mention is actually an MS standard that Apple have acceded to. Again, there’s no problem: it doesn’t matter whether the W3 sets the standard, or Microsoft, or Apple. What matters is that the designer and I have a common point of reference.

That’s what good about standards: they provide a common point of reference and so make communication easier. Let’s say the designer decides that a basefont of 13px Verdana is appropriate to his design. Well, **because he knows what my settings are likely to be** he can set that on the body of his document indirectly by specifying something like 80% Verdana.

I’m happy for him to make that judgment. If the page doesn’t suit, I’ll re-size *after* I’ve seen it.

If I *really* needed to I could use that control to make a rough alteration to all documents before I see them. That’s good: but there’s no need to get hung up it.

The spec seems to assumes the designer will be setting a basefont appropriate to his document.

Similarly, as Joe Clark points out, the spec assumes the designer will be styling hyperlinks:

In each case, let’s go with the spec. Let’s not have every page on the Web look the same.

November 18, 11h

Here’s a practical tip: when you start working with the CSS for a page, or when you’re doing major changes to existing CSS, make all css internal to avoid any caching problems. You also reduce the risk of confusing yourself by editing the wrong file and wondering why you can’t see the changes.

November 18, 11h

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.

- 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 stylesheet 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).

- When an element appears only once in a document, use an ID insteado 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.

- 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.

- 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.

- 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.

- 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.)

Sorry to be the devil’s advocate.

November 18, 11h

And next link for Best CSS Practices.

November 18, 11h

Find a formatting/indenting style that you like and stick with it. It will make your CSS files more consistent and easier to maintain.
Even better would be if everybody could agree on the same style… :)

November 18, 11h

#39, Motekye: "Use floats for layout whenever possible."

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

My mantra has long been: Floats are evil… even though I still use them, but only for "floats" and not for layout.

Lately, I’ve been doing layouts using relative/absolute positioning, sort of like described in Doug Falby’s "Flexible Layouts with CSS Positioning" at

By crafting sensible sections/containers within a page, they can, for me, easily be moved around and styled independently.

Thus, my advice will be:
"Know as much as you can and wisely choose the layout/styling technique thats best for your project. ."

November 19, 01h

#47 - Jim: “What’s the use of text-decoration:none if it’s improper to use it?”

Its there in case you want to use it. You can just as easily use the following to follow best practices and allow for visual style:

– code –
* Links
p :link {
text-decoration: none;
border-bottom: 1px dotted blue;

* Mimic Moz: Acronym tags in IE for useability
acronym {
border-bottom: 1px dotted #AAA;
cursor: help;
– code –

That way, you still have the underline, but you’ve got a little more control over the formatting of it. You might also want to remove the underline in navigation menus, which is common practice.

My tip?

- Don’t style the scroll-bars! Ever! People know what colour they are already. Most even set the colour themselves, using the UI widgets of their selected OS (most likely windows). Colouring them will mean they have to activly look for them rather than glancing. They’re part of the window, not part of the page, so leave them alone.

Michael says:
November 19, 02h

border-bottom: 1px dotted blue;

Why not? That’s certainly one option among many. It’s probably best not to indicate a link *only* by colour, but there are many solutions to that. As Joe Clark pointed out in the link I gave, the styling options are in the spec.

But I don’t think this is the kind of thing Dave was looking for. I *think* this is the kind of thing he meant:

* * *

Suggestion: You don’t need to use text-transform: uppercase on the first letter of a word that you’ve used “font-variant: small-caps” on, provided you use normal “title case” in your HTML.

Reason: You get true uppercase with “font-variant: small-caps” anyway wherever you use a capital, eg. with the “N” in “News”, so there’s no need. But if you do use “text-transform” on “first-letter”, you get a doubling effect in the current version of Safari:

* * *

I’ve seen just that on occasion, and, as Hyatt says, it does look ugly. Apparently, it will be fixed in the next release. But why use “text-transform” where you don’t need to anyway?

November 19, 03h

Regarding all the comments about font-sizes and types, my tip is to design your website however you want. Then, when you’ve got it looking pretty and are in your testing phase, flip over to Mozilla.

Open the preferences window, and go to “Apperance > Fonts”. At the bottom, there’s a checkbox which says “Allow documents to use other fonts”. Un-check this. This will cause your default font to take over from any font set, and is a quick way to test what will be viewed for that poor user who doesn’t have Arial/Verdana/whatever-standard-font on they’re system.

Then, while still in Moz, hit Ctrl and + or - a couple of times. This will change your font-size. If you’re site doesn’t go wacky when you change the font-sizes, you’re on to a winner.

Also, [in true jedi styliee] be mindful of exactly what you’re using. As Micheal says, why use “text-transform” when something else might work better for you? Try to ensure you’re not doubling up on code to do something simple. I add another phase to my CSS development - trimming. Once I’ve got everything looking pretty and working, I try to “trim the fat”, as it were, so I don’t clog my pipes up. Then I re-test. You might wish to do the same.

jgraham says:
November 19, 04h

> 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)

So it’s only worth worrying about if you expect anyone with a web browser to visit the site ;)

Remember kids, a browser without a parser is called telnet.

(As a serious point, I’m surprised with just how much I disagree with here. A lot of these “best practices” are just arbitary favourtism for a particular way of working. Oh and as for underlining links; my feeling is that underline was a poor choice of link highlighting in the first place, since it makes them less legible. I’ve also yet to see someone fail to grasp that something is a link just because it’s not blue and underlined; I think the link pattern recognition in most people’s brain is better than that. In fact, given the choice, I’d say blueness is a more important link quality than underlines, and removing either is the least usability problem that most websites have. It’s far harder, for example, to guess what the main navigation is suppoed to be on most sites. In this case people often use graphics in place of text and follow none of the “this is a hyperlink” conventions such as underline, or consistent text colours)

November 19, 06h

In reply to igraham:

I think you might be missing the point of useability with regards to linking.

Its fine to ignore best practices for links if your intended audience is as web-savvy as yourself, or even more so. Otherwise, stick to what works.

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.

These best-practices, or arbitary favourtism as you term it, are what will eventually make the web useable for everyone. More and more people are starting to follow these conventions, which have in one way or another been agreed upon to get the message across regardless of media. The big companies, such as sprint and adobe, are following suit. These sites are borrowed from and based upon by lots of designers, who will hopefully look at the code and follow suit too.

Praise be to the day when all sites are useable on all media - TV, PC, PDA, mobiles, etc - regardless of physical abilities.

Michael says:
November 19, 06h

“I’ve also yet to see someone fail to grasp that something is a link just because it’s not blue and underlined; I think [most people’s] link pattern recognition … is better than that.”

I agree, of course, as you’d expect. It’s easy to miss a wider context for these things - as with font-sizing. (I may want to move *a range of values* in one direction or the other with the so-called “preference” without wanting to move to *a point*).

I think there would be many cues here - more than we are probably aware of or even could list: such things as linguistic context, for example.

It seems to me that modern browsers’ support for the “hover” pseudo-class is a good thing. I suspect people sometimes work partly on the basis: if you prod it and it responds, it’s a link. :-)

David L says:
November 19, 08h

How about just “Consider your audience.”

This will dictate which browsers to whom you need to cater (NN4x, screenreaders, WebTV) and which design choices to avoid (such as underlining all links, small fonts, etc.).

And, regarding comment 18’s point about the “name” attribute, this has been removed from XHTML 1.1 in favor of “id”:

November 19, 08h

Motekye wrote: - For images and objects: Set the height and width of objects with CSS, rather than width and height attributes.

What is the advantage or rationale for that?
I don’t know of any advantage and it removes useful info from the HTML.

Oliver Schwarz wrote: Do NEVER EVER use numeric characters in your classes and element titles. Bad example: span.tree123

Why? I know you can’t *start* a classname with numerals, but what browsers have trouble with numerals in the middle or end?

Here’s a tip to add: When troubleshooting what is covered by a CSS selector or by inheritance, add a stand-out color (like red or orange) to the rules to help you see what is affected by that selector.

and “Just Say No to Colored Scrollbars…” they should go the way of BLINK and MARQUE. Useless.

jgraham says:
November 19, 09h

I should say that my point about arbitary favourtism and my point about links weren’t really suppoed to be connected. I see the argument for always having links blue and underlined, and while ‘m all for stes being as transparent as possible, I just don’t think that it’s a correct argument. For a start, I think that underlining harms legibility, especially where there are multiple links, long links, or a list of links. For example, underlines make t difficult to see descenders so that characters like i and j are hard to distinguish. Using border-bottom is actually better in this context as the border sits below the descenders and so doesn’t interfere with the text so much. As for blueness; even as a non designer, it’s clear to me that no designer is going to make her links blue if blue clashes with the other colours of the site. Instead, a typical approach is to make the links a similar (or, in the non-technical sense, complementary) colour to other site elements (such as the navigation bar), yet have high contrast with the surrounding non-lnk text. So my “best practice” statement on links (which is really as design “best practice” statement would be:

Make navigation elements easilly identifiable
All navigation elements, including site navigation, and links within body text, should be easilly identifiable when casually scanning the page. In the case of navigatioon elements, this means placing the elements in a conventional place such as the top or side of the page, and ensuring that the elements are styled in such a way that it is obvious they are navigational elements (this might be acheived by appealing to a common user interface metaphor such as tabs, or by ensuring that the links appear similar to other links on the page). Links in body text should be styled in such a way to appear distinct from the surrounding text - schemes where the body text and links have similar colours are likely to lead to user confusion. Use of the :hover pseduo-selector for link elements can help to identify them as functional elements which will respond to mouse clicks. If in doubt, the most widely recognised style for links is blue underlined text.

November 19, 10h

Welcome to the real world, nearly 90-93% of the whole world use IE so if a customer asks me to make him a commercial website or if I run a web-design company, obviously i’m not going to concentrate my efforts on Mozilla/Firebird/”put here your minority and ¿0.5%? used browser”, that would be a stupid movement and an enormous commercial mistake …

Yes, all of us would want a perfect world with blue sky, green grass, a bright sun and a 95% of users using Firebird but the reality is completely different. If you can’t see it i’m sorry, wake up!.

PS: And yes, I use and work with open-source software, i work on open-source projects and I try to expand W3C standards on my company and with my friends but i still work primarily with IE because is the browser that 100% of my customers (since 3 1/2 years of projects) use. Call me stupid if you want, i would prefer to say “smart”.

Dave S. says:
November 19, 11h

Discussion has been moved to the follow-up: