CSS Crib Sheet

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.

Technorati Tags: CSS Crib Sheet