css organisation: putting it all together
Ok, so no series is complete without an example. I’ve created two very simple pages, which should look the same as each other. However, they will degrade gracefully in less capable browsers.
The pages all have their CSS inline, except for the reset CSS. They have been tested on FF3.6, Safari4.0.5, Opera10.5beta, Chrome4 and MSIE6+.
The first page achieves cross browser css using JavaScript, alphabetised style properties, hyphenated classes and short consistent naming conventions.
The second page uses conditional comments, browser hacks, style properties in any order and camelCase class names.
My (biased) opinion is that the first page’s CSS is easier and quicker to read, debug and update. I can clearly see all the browser adjustments for a specific rule and if I need to make a change to a property or add a new browser or browser version override, I know immediately where to look. If a user has JavaScript turned off for whatever reason — try it — the page doesn’t explode in any of the tested browsers. If I walked into a new contract with a CSS code base similar to this, for a change, I would be one happy chappy!
What I don’t like about the second page is all the scrolling I have to do to see all the browser and browser version overrides. What makes this worse is that generally you would put the Internet Explorer hacks in separate files, this would mean having to tab back and forth between files, it really slows you down and as I’ve already said, you have hacks everywhere. No thanks, not for me; if it has to be done, I like to be able to see it all in the one place.
So, at this point I’d like to ask — if anyone out there in internet land actually reads this blog — What do you think? Which is your preference and why? If you are generally a page two kind of developer, would you consider doing things in a page one kind of way in the future? And if not, why not?
