Re: 7 Principles of Clean and Optimized CSS Code
Jens O. Meiert, August 19, 2008 (↻ August 16, 2013).
This entry has been written by Jens the Web Developer.
Tell me, is Smashing Magazine sometimes misusing its power, or is their power sometimes abused? Yesterday’s post features 7 Principles of Clean and Optimized CSS Code, but one of them is not at all advisable, and others are lacking. Let me do what I did before, comment an SM post:
- Use Shorthand
- Axe the Hacks
- Use Whitespace Wisely
PruneFrameworks and Resets
- Future-Proof Your CSS
- Document Your Work
- Make Use of Compression
Using shorthand properties is the single easiest practice you can do to cut down your code
Axe the Hacks
But now we know that using conditional comments to serve hacks correctional declarations for IE 6 and IE 7 is an accepted practice
It’s not. I’ve no intent to go through all these debates again (though I’m working on another post on Conditional Comments featuring examples for those who need to see or touch something), but, Conditional Comments are a maintenance problem, by design. There is no difference between changing HTML by changing an IE style sheet, and updating
font elements. In both cases you’re changing HTML for presentation. When you change presentation you only want to edit the contents of your style sheets. You don’t want to manage style sheet references—yet Conditional Comments force you to do exactly that.
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.
Use Whitespace Wisely
Whitespace, including spaces, tabs, and extra line breaks, is important for readability for CSS code.
Prune 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 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. Just be mindful and notice when you could have done everything yourself.
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.
<code>will likely go unused on my Aunt Martha’s recipe blog. A design portfolio probably won’t ever use
<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.”
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 a reset set of rules can help keep your work optimized, but they should not be accepted in their default state.
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, I’m probably nit-picking.)
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.
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, not to mention mod_gzip.
Enjoy the most popular posts, eventually including:
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.
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.
On February 10, 2009, 19:21 CET, karl said:
For Apache 2.0 it’s mod_deflate. And I recommend the mYUI script that is a .sh scripts that runs server side and will compress all your JS files and CSS files with the YUI packager / compressor.
Leave a Comment
Unfortunately, comments are closed.