Great CSS Techniques and the Simple Truth Behind Them
Post from March 11, 2008 (↻ July 3, 2015), reflecting Jens the Developer.
There is a simple recipe to judge CSS techniques: Does the method in question require HTML additions and modifications beyond introducing IDs or classes?
If yes, the technique likely is not very elegant, in fact, might be inadvisable, depending on the strictness you’re applying. Personally, I avoid and discourage to use HTML-heavy techniques. Both theory and practice show that you’re better off looking for alternative solutions since presentational HTML changes do not only mean worse code but also particular problems concerning maintainability.
While it’s nice to talk about such problems, two examples may help the argument:
Questionable: Nifty Corners
The initial proposal for rounded corners asked for the following markup to be used in conjunction with some extra CSS styling:
<div id="container"> <b class="rtop"> <b class="r1"></b> <b class="r2"></b> <b class="r3"></b> <b class="r4"></b> </b> <!-- Content --> <b class="rbottom"> <b class="r4"></b> <b class="r3"></b> <b class="r2"></b> <b class="r1"></b> </b> </div>
Recommendable: CSS Sprites
CSS Sprites are a nice way to create delay-free hover effects that save performance by avoiding HTTP requests. Let’s see if the theory that lovely CSS techniques live without HTML changes holds true:
<!-- Untouched HTML. -->
❧ This has not quite been a scientific approach to CSS methodology assessment, but it should work as an indicator. HTML modifications are usually the point of criticism when it comes to new techniques, including those “you can’t live without” or that are “for effective coding”. Presentation should not require the structure to be changed, as that means blending the two.
About the Author
If you have any questions or concerns about what he writes, ask him to explain, or share your own position by sending a constructive comment or email. (Then, if you think something could be of interest to Jens, recommendations for excellent literature are always welcome.)
Taking such a pure stance on code sometimes forces me to decide that something isn’t possible (yet). For example, is there a way to do rounded corners or some other image-based border style on a div of flexible dimensions?
Before I read any article on a tricky CSS idea, I check to see if the author outlines what support is like in major browsers. I wish authors would similarly state outright if extra HTML is required.
This may be a simple analysis, but I agree and think you are totally right. If you are adding markup then you haven’t fully separated structure and style.
Dave: we are all waiting for CSS3’s border-radius to be well implemented across the board!
There is always a price you have to pay
On March 12, 2008, 12:10 CET, Gemma said:
I’d love to be able to be semantic all the time, cut off the extra added divs and such whose only purpose is to align stuff (backgrounds that are stupidly complex most of the time).
My rule of thumb tends to be:
1) Mark up content semantically and cleanly.
2) Style it as per the design, as far as possible.
3) Add extras to make it fit the design exactly.
This tends to keep it as clean as humanly possible while still giving in to the fact that clients always want the design thats the hardest to build in a semantic manner.
Jen, I briefly looked over the CSS3 and Nifty corners that you posted in regards to rounded corners with CSS. Also the w3c(always there for me).
I have had a lot of fun tinkering with rounded corners and noticed that if I base a similar technique with background images it was taking up about 18 images! Not to mention extra non-semantic wrapper and enough css I could fall over. I think that Nifty Corners hit it right when they said that you used about 18-20Kb or so.
Great CSS technique, concise and to the point.
I’m so sorry I forgot the (s) in your name…I apologize about my typing error. Again apologies. Jens*
I also apply an additional rule - will the particular hack be needed in a few years time?
Again, rounded corners: already an established part of the spec, supported by Mozilla and by WebKit: those browsers get to show off, IE gets to look a bit square (which it is).
I tend to take a pragmatic approach to these matters: for me, its a case of deciding whether the means adds enough value to justify the ends (generally, I find it does not).
I agree with you in principle, though: that so-called “nifty corners” technique is very ugly, and not something I would use personally. However, I am not so pedantic that I object to an extra
spanhere or there, either. It’s all about balance, IMHO.
On June 1, 2008, 1:08 CEST, Ludde said: