The Zen of CSS design: a review
Since most of my readers are very interested in CSS and many of you know who Dave Shea and Molly are, I thought I’d try and write a review of their the Zen of CSS Design book, that I just finished reading. One reason is to give my personal view on it, and another is to maybe give you some idea if this book is for you or not.
First, I just have to say that in the “About the authors” page, it’s hilarious that (to me) Dave looks like Molly’s boy toy… π
With that aside, let’s start from the beginning. I love the cover and the format of the book. Glossy colored pages are so much nicer than the developer books I usually read. When it comes to the format, I’m not sure if the credit should go to this book, or to the New Riders publishing company (I don’t know, since this is the first book from New Riders that I’ve read), but either way, I love it.
The book is about the incredible css Zen Garden web site, which is a showcase for using the same well-structured XHTML file for over 160 different designs, all solely based on the content of their corresponding CSS file. The web site is an invaluable tool to show people what can really be accomplished with CSS, and this book covers some of the different designs’ code, color, images, typography, concept etc.
Maybe this is just me, but I felt that the book is mostly written too much from a designer’s point of view. And to be fair, designers are the ones behind the different designs, but I have never myself, or met any other that has, had the role of being the designer and the one coding the CSS. In “my” world that’s two different roles, normally an AD and an Interface Developer. I don’t know what it’s like in the rest of the world, but here in Sweden the word “Web Designer” has a bad ring to it; to me it symbolizes the first developers in the beginning of the commercial internet era, the ones that were hard-coding the pages and doing everything from the design and copy writing work to the interface coding.
With that said, I have to admit that some of the topics in the book are things that will (probably) never apply to my professional role and I won’t browse through those chapters as a reference in my daily work, but they were still interesting to read one time.
Getting back to the format of the book: every chapter has small boxes in the margin, usually named “tip” or “note”. They turn out to be links to very useful web sites with solutions to and ideas about handling different scenarios. Personally, I’d wish that the content of some of those linked web pages were discussed in the book (some of them are mentioned in the text, but not much more). I think the book would’ve been more interesting if they had been a part of it, instead of only focusing on having a different css Zen Garden design as a starting point all the time. On the other hand, maybe that’s the whole point of this book. I don’t know. But to me it could’ve been the ultimate CSS/interface developing book, but now it’s “merely” a guide to the different designs in the css Zen Garden.
The chapters are:
- View Source
- Design
- Layout
- Imagery
- Typography
- Special Effects
- Reconstruction
I think it started off great with the View Source chapter, but after that it just wasn’t as intriguing. Bits and pieces of the other chapters were interesting per se, but not extraordinary. The last three chapters got more interesting though, starting with chapter five, Typography. I don’t regard myself particularly skilled in that area, so I gained something from it. Then chapter six and seven, Special Effects and Reconstruction, respectively, had some nifty things to pique one’s curiosity.
The Closing Thoughts was one of the better parts of the book, with good advice and introducing a link to Dave Shea’s CSS Crib Sheet.
However, there are two things that the book promotes (in some places), which I don’t like:
- Pure CSS Menus
- I can live with changing the look of a link with :hover, since it’s more of a state, but I think creating menus belong in the behavior layer.
Take, for instance, this sentence in the part about the Tulipe design:…you can always default to JavaScript for dynamic menus. There’s nothing wrong with that, but CSS allows you to do it more elegantly…
It’s exactly this general attitude, that it’s so easy and elegant to do it in the CSS file, that I personally don’t like. I express my opinion more detailed in my Three separated layers, capisce? post.
- Browser elitism
- The book is full of mentioning things that won’t work in IE on a PC, and I agree that it’s important that all of IE’s shortcomings are brought up. I also like that it is being addressed in how to write the CSS code to handle them. The thing that bothers me, though, is that there are several designs covered in this book that delivers more stunning designs and effects to more competent web browsers, like Firefox and others, while serving a more bland version to IE.
That, to me, is showing a browser elitism attitude, and that way of approaching things is exactly how IE got away with its different proprietary techniques that later resulted in people writing code that only worked in IE. Sure, in the book’s case, the extra effects are written according to the W3C recommendations, but personally I think that one should do it’s best to deliver an equal design and its effects to all of one’s targeted web browsers.
Coding wise, as in all books, there are some minor flaws and typos that aren’t even worth bringing up. One thing, though, that got to me, was a part where catering to IE 5.x incapabilities of centering content with text-align
alternatives, instead of the correct way with using width
and margin:0 auto;
, is refered to as a hack. The code:
body{ text-align-center; } #container{ text-align:left; }
Using text-align
in a clever way is not a hack to me. The Box Model hack is a real hack. Maybe I’m just nitpicking, but I think its a vast difference between a smart, validating and correct solution and an actual hack.
Another thing:
In some chapters, especially in the last one, there are numerous places with sentences like:
If you go to the web page, you can see the full CSS…
Sure, but what’s the point of buying the book then (except for the explanations)? I understand that the different chapters can’t have CSS code running page up and down, but it would’ve been nice with an appendix of the different CSS files, to get a feel of the whole structure (and not having to resort to a computer, while sitting out in the Spring sun and reading…).
All in all, despite my criticism above, I do like the book. It’s a good read, but not as amazing as I had hoped for. Too much focus on the design, and to little of solving problems all the way, discussed from every angle. Maybe too many designs covered instead of focusing more thoroughly on fewer ones?
However, I’m convinced that many people will gain a lot from reading it, and it shows off some cool CSS.
PS. A little bit over a month ago, Tommy wrote a post about this book and some of his opinions about it. DS.
The <code>text-align</code> hack is a hack, because it relies on browser bugs. The <code>text-align</code> property should only affect inline boxes, but IE allows it to affect block boxes as well.
I don't agree with you (or Derek) about browser elitism. Using proprietary things to provide a "better" experience to a certain browser, that's a kind of elitism. But using standards and allowing the design to degrade gracefully for less competent browsers, that's the whole point of accessibility.
Should we always design to the lowest common denominator? If so, who decides what that is? Why should we dumb down our designs so that they look identical in Firefox and IE5, while Nescape 4 is left out? Where do you draw the line?
I'm with Tommy on the so-called browser elitism. Using standards that are not yet supported by all browsers is very different from using proprietary features.
And it's not only IE/Win that gets left out. Safari, my main browser, for some reason does not make form labels clickable. So to avoid being "elitist", I should either stop using labels alltogether or write a JavaScript routine that makes labels clickable. Nope, don't think so.
Tommy,
Regarding the hack statement: To me, a hack is something that's prone to break in some way in coming web browsers. In this case, it's just taking advantage of a wrongly implemented feature in a web browser that is soon to be obsolete.
Tommy and Roger,
I don't think that we should design to the lowest common denominator, but since IE 5.x and IE 6 still has almost 90% of the web browser market, shouldn't that be the way it should be interpreted for all users? I couldn't motivate to my customers and project managers (and Art Director, for that sense) why the web site look and is experienced differently (and better) in some web browsers that are a minority amongst the customers.
Believe me, I'm really eager to do all sorts of cool CSS stuff, like attribute selectors and so on, but when the time is ripe.
If you want to use :focus or labels in forms, go ahead. But I think that to have totally different designs just based on CSS support is not the way to go.
Small correction: CSS Zen Garden has not only "over 160 different designs" as you put it, but also over 600 different designs. Much more interesting and impressive π
Faruk,
Ok, but is it 160+ official ones then?
Oh, and I'm completely with Tommy and Roger. Making more rich sites for the browsers that do support Standards fully, and giving more bland versions to all browsers that don't, that's not really elitism, it's a push to the browser developers that aren't doing their job right, to do their job right!
It's one of the few things that we as normal webdesigners can actually do to push them into keeping up with standards.
Robert,
Yes, 160+ official ones, but most of the unofficial ones are also great. And no, I'm not saying that because my CSS Zen Garden design didn't make the Official list (it wasn't showing right in Safari, but back then I couldn't test that π ), I'm saying that because I've seen almost all 613 designs that are on the site right now, and at least 400-450 of them are very high-quality. π
That depends on whether you want web standards to be made by open organisations or by the corporation that happens to have the most money at a specific time.
Microsoft have shown over and over again that they are not interested in supporting web standards; at least not standards developed by someone else. If we grovel at their feet, development will stop until Microsoft decide to market something new. I don't like that.
Rewarding those who support web standards by using a compliant browser is not wrong, IMHO, as long as everything degrades gracefully. It's different if you deliberately make a page look worse in a particular browser (like Microsoft did for Opera); that's elitism. Progressive enhancements isn't.
Faruk,
That's where our opinions differ.
I still haven't met any project manager or client that would accept some "spicing up" in the more capable web browsers, they want their web site to look and work the same in the major web browsers.
If I were doing a private web site, of course I'd add some CSS fun for Firefox, Safari and Opera. But not in a business situation.
Robert,
Sure, business situations won't generally allow it, but that doesn't make it elitism.
It falls outside of profitable and sensible business ethics, but that's not elitism (to me). But Tommy already explained the details on that π
Faruk,
To clarify then:
Using it in a business situation would, in my eyes, be elitism, too eagerly promoting web standards.
Using it privately, be my guest. I won't call you names. π
I just cannot see progressive enhacement as elitism. The whole idea is using standards (in this case, CSS) sensibly and provide graceful degradation. The kinds of things we're talking about (:focus on form controls, :hover on any element, etc) are just little nice-to-have extras, not critical functionality (unlike the zillions of "web" applications that require ActiveX and only work in IE/Win). Have you actually talked to art directors, project managers and clients about it? If so, I'm surprised by their attitude. I very rarely have any problems of that kind with progressive enhancement.
Elitism in itself might be a harsh word, but since Derek described the phenomenon, I thought I'd use it in the context.
For instance, using the :focus is one thing that shouldn't normally be an issue, but I was mostly referring to designs that have totally different layout basically depending if the visitor's web browser is IE or not.
Regarding ActiveX and its similarities, they are things that I shy away from as much as you (if not even more).
Ah, totally different layouts are another story. Sounds like something from the nineties π
Roger,
Yes, that was my main concern. π
However, I know of people I've worked with that wouldn't allow tiny :focus or :hover effects if it wasn't possible to achieve it in all targeted web browsers.
Yeesh. Elitism was clearly a poor choice of word on my part.
Two quick points…
I don't see progressive enhancement as elitism either. I guess what I see (and was the point of my original posts) is that it seems that people are adding in the CSS enhancements, seeing that it works in Firefox and other "good" browsers, and leaving it at that, without consideration for adding JavaScript enhancements as well. In my opinion, it *appears* that people are stopping short of providing a better experience for IE users on purpose, knowing full well that many of the enhancements could be easily provided to IE users (for example) with a little scripting.
That's the practice that I'm questioning. Forget about forms for a minute and the :focus pseudo-class and whether or not it belongs in a JS behaviour layer or not, as that seems to have clouded the issue over on my blog. Think about tabular data – you can easily add a tr:hover rule that works in good browsers but not in IE. Is that being added as eye candy, or as a usability enhancement? I suggest that it is a usability enhancement, and therefore deserves to be scripted for IE users. So, I add in another layer, with intelligent DOM scripting, that still follows the principles of Progressive Enhancment and web standards to provide a better user experience to the users. That's the point I was trying to get across on my blog, but, as I said, it got really clouded really quickly over there…
Derek,
Good to see that you're joining the discussion!
I totally agree with you. If it's something more than just, for instance,:focus on a form element, it is definitely a usability enhancement.
If it then turns out that it will be an easy add-on through script for less capable web browsers, it should be there, out of respect for those users.
Many developers seem to assume that all IE users have chosen it as their first choice web browser. That's normally not the case, it's just about less knowing visitors that use the web browser pre-installed on their system.
I think they have a right to the same user experience, if it's a small feat with a script.