Re: 7 Principles of Clean and Optimized CSS Code

Jens Meiert, August 19, 2008 / October 2, 2008.

This entry is filed under Web Development.

Tell me anyway, is Smashing Magazine sometimes misusing its power, or is it sometimes abused? Yesterday’s post features 7 Principles of Clean and Optimized CSS Code, but in fact, at least one of them is not necessarily advisable, not at all, and others might be missing. So let me do what I once did already, let me comment a SM post:

Index

Use Shorthand Properties
Axe the Hacks (Conditional Comments)
Use Whitespace Wisely
~~Prune~~ Don’t Use Frameworks and Resets
Future-Proof Your CSS
Document Your Work
Make Use of Compression

Use Shorthand Properties

Using shorthand properties is the single easiest practice you can do to cut down your code ~~[…]~~

Roger that.

Axe the Hacks (Conditional Comments)

But now we know that using conditional comments to serve hacks correctional declarations for IE 6 and IE 7 is an accepted practice ~~[…]~~

Well … it’s not. I’ve no intention to go through all these debates again (though I’m working on yet another post on Conditional Comments featuring examples for those who need to see or touch something), however, Conditional Comments are a maintenance problem, by design. You might very well argue that there is no real difference between changing HTML by adding or changing some IE style sheet (for presentation) and changing HTML to update the colors specified with font elements (for presentation). And as we all know, CSS’s biggest strength still is improving maintainability anyway I guess.

Also, while PPK makes a good point, this maintenance advantage you’ve got when making proper use of HTML and CSS allows you to compensate for issues with “hacks”. So even when you don’t avoid using hacks or filters, which is usually recommended, and even when you go for the most fragile hacks, using CSS allows you to adjust within seconds.

~~[…]~~ even recommended by the Microsoft IE development team.

Oh, really.

Use Whitespace Wisely

Whitespace, including spaces, tabs, and extra line breaks, is important for readability for CSS code.

Tentatively agreed.

Prune Don’t Use Frameworks and Resets

If you’ve chosen to use a CSS framework ~~[…]~~, take the time to review the documentation as well as every line of the CSS file. You may find that the framework includes some rules that you don’t care to use for your current project, and they can be weeded out.

… and please, take the time for that and compare to what it would have taken you to come up with an own, tailored, optimized solution. I don’t need to talk about frameworks again now, do I, repeating that they’re never the best solution? However, the advice given does not just point into the right direction, it’s good, so I don’t want to be unfair: Tailor your framework of choice, yes. But watch the clock.

This goes for resets as well. YUI Grid CSS uses a reset, and Eric Meyer’s Reset is also very popular. Resets are great to use because they help to neutralize a browser’s default style. But if you know the nature of the site you are building, you may find some declarations that you know you’ll never need. <pre> and <code> will likely go unused on my Aunt Martha’s recipe blog. A design portfolio probably won’t ever use <sub>, <dfn>, <var>, etc. So ditch what you don’t need.

Absolutely, so that advice is good as well. However, and that’s why we probably find this so exciting, what is more efficient? Just writing down the style sheet, or customizing a reset style sheet to write down the style sheet afterwards (or vice-versa)? Looks like some cost of problem thing as well, apart from all that stuff I once talked about when criticizing “resets”.

Don’t get me wrong – Tony’s remarks concerning frameworks and resets are good (and he’s making the point in a nice, constructive way). I just used to come from another direction before, and mainly want to “inspire” to think about the process and efficiency as well. I’m not convinced that using a framework and a reset that is then going to be truly customized and tailored is actually faster than doing something from scratch.

Using a framework and/or a reset set of rules can help keep your work optimized, but they should not be accepted in their default state.

Indeed.

Future-Proof Your CSS

Another way to optimize your code is to separate layout-specific declarations from the rest of your rules.

Now I’d like to see a definition for “layout-specific declarations”. And why and how to separate declarations from rules. And how that makes the CSS in question future-proof. (Well, probably nit-picking now.)

Document Your Work

Documentation, including markup guides and style sheet guides, is not just for group efforts — they are just as important for a one-man design team.

~~[…]~~ separate documentation is a great way to keep the code focus and free from bloat.

Absolutely.

Make Use of Compression

It is important to note that these applications do their best to minimize errors, but they aren’t always perfect. Also, they work best when browser hacks are not included in the file set (which is yet another reason to keep those hacks external).

I don’t get this argumentation. And I suggest to use other tools then, for instance Peter Bengtsson’s code compressor, apart from all the other tools available to analyze and optimize code, and not to mention mod_gzip.

However, that’s it. No offense though, Tony. I’m sometimes passionate.

Enjoy the most popular posts, probably including:

Comments

On August 20, 2008, 8:45 CEST, Markus said:

As I was reading the SM article, my first thought about the Conditional Comments advice was that you surely wouldn’t support this view I’m still thinking about this problem myself, since CCs are really “comfortable” while the use of hacks seems to be more complicated. Let’s see what your see-and-touch-article says, looking forward to that one.

I didn’t get the future-proof part either - but I think it comes down to the general structure of CSS files. And that’s as far as I can see based on personal choice & hard to argue about.
On August 21, 2008, 20:30 CEST, Jens Meiert said:

my first thought about the Conditional Comments advice was that you surely wouldn’t support this view

You bet, Markus Thanks for dropping by!
On August 24, 2008, 11:02 CEST, Kroc Camen said:

A CSS file is such that you can throw it away easily and start again. I could design my website any way I wanted without ever changing the HTML.

Clean and separated HTML/CSS means that parts can be replaced. That’s what future-proof is about - the ability to adapt to *changes*.

Being bit-rot proof is an entirely different matter!
On November 20, 2008, 21:10 CET, John C. Reid said:

I have started looking at CSS frameworks and reset style sheets lately, and I have come to a basic conclusion.

Why reset? Set instead. Simply put, replace your reset style sheet with one that SETs all the basic styles to the defaults you would like to start from instead. You still get a good baseline across browsers by setting all your styles to a standard format. I just don’t see the point of doing something to force me to specifically undo it later. I would much rather start with a style sheet that has a reasonable starting point that overrides the differences between browsers while at the same time making elements appear as I would expect them to everywhere.

So how about we see the death of the reset style sheet and the birth of frameworks with set style sheets. I think I will work on creating my own set.css in the near future.

Jens Meiert