Slashdot Mirror
Designing With Web Standards
Jeffrey Zeldman is one of the best technical writers whose work I've had the pleasure of reading. He is obviously well-educated with regard to the subject, and his passion for the work really shows through. Still, he never comes across as a zealot -- his style is even-handed, thoughtful, and easy to comprehend.
The first part of the book ("Houston, We Have a Problem") is the reason I give a rating of "9" rather than "10." Zeldman spends a perfect length of time on background and history of Web standards (why they're here, and what designers did before they emerged). However, this section seems to suffer from what many technical books suffer from: a case of "We'll see this soon"-itis. While this is perhaps unavoidable in such a treatise, it is nonetheless apparent. Still, it's only marginally distracting.
The meat of the book comes with "Designing and Building." Zeldman first talks about modern markup, then explains the variations on XHTML (i.e. Strict, Transitional, Frameset) and how each ought apply to your design. Here we see more theory than practice, though, but this is welcome -- it lays the foundation for a more cerebral look at distinguishing markup from design. Once Zeldman explains the nuances of that topic, we moveon to the redesign of a Web page constructed with a hybrid table/CSS design complete with all the excellent effects we hope to see in modern pages.
After working through this redesign, Zeldman talks in more detail about the CSS box model (and the browsers that break it), typography, and some of the quirks that Web designers must deal with. Next he touches a bit on Web accessibility--a must-read for everyone, whether you think so or not.
While Zeldman isn't incredibly thorough here, he doesn't need to be--it's a book on Web standards, after all, and this chapter serves to show how accessibility can still be achieved within those standards. He also suggests a couple of other books for more information.
Finally, Zeldman walks the reader through a redesign of zeldman.com, basically as a hands-on summary of the book, and as a guide for future projects. Also included is a "Back End" (i.e., appendix) showing some excellent information about each major browser.
Too often, a book or Web site on XHTML/CSS will dwell only on the "how"--this book shows the "how" and still explains the "why": Here's how you set up an id'ed element; here's why we do that, rather than using a class. It's already opened my eyes to many things I thought I had a handle on, but now realize that I only knew in a cursory fashion.
So, ask yourself: Do you want to design a Web site that will work for everyone, regardless of their platform? Do you want to make sure your Web site is future-proof? If so, you need this book.
You can purchase Designing With Web Standards from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
You mean it's not enough to make sure it works in IE6 on Windows XP?? I wish more web "developers" were concerned with standards. Not only does it make their job easier, it makes it easier to use their sites (assuming the browser developers are equally concerned with standards).
This is my sig. There are many like it, but this one is mine.
while you believe there is nothing wrong with flash, there is quite a bit wrong with it in how people utilize it on the web. it is great for menus, but only when necessary. it also doesn't account for usability standards in any way shape or form, expecially for accessibility issues when people do not use a mouse, or are reading from a prompter.
Where is the completely compliant web site that thet reviewer was designing prior to reading this book? It would be pretty darn interesting to see what it looks like.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
It seems to me that the larger problem with web standards' adoptions is that many managers would prefer to just have crap, so long as they can have it "right now", and forego the longterm financial savings that web standards coding can provide. I would like to see a book on how to implement a web standard or two that will really save a lot of time right from the beginning, versus the kinds of major changes that take weeks to months to implement -- weeks & months that no small-business manager wants to pay for.
stuff |
Yes it is, as long as its doctype declaration doesn't claim it's XHTML or something. Standards compliance has nothing to do with following the latest standards, it has to do with following some standard. 99% of the stuff on the web today doesn't follow whatever standard it claims to follow.
Don't blame me; I'm never given mod points.
It will be standards-compliant to its specified version number. If you're compliant with HTML 4.01 today, you will be 5 years from now even if the current spec is XHTML 23. You may not be up-to-date, but you're compliant with the specified version, and a client will be able to render the page with the appropriate DTD and so forth. (afaik)
First, a reminder that this is 2003, not 1998, which was the year IE4 and Netscape4 were introduced. Since then, Mozilla has come, and with it Netscape 6 and 7. Also, we've seen the arrival of Konqueror (and Safari) and Opera.
Netscape 4 is dead: don't worry about it beyond getting your sites to still be legible in it.
Gecko based browsers, Konq, and Opera all do very well with W3C standards.
IE, however, has not had a major rendering revamp since version 4. The biggest change was for IE6, which is actually less compliant than previous versions. Sure it fixed some things, but broke many more.
Among web designers I know, IE is quickly gaining the hatred that had previously been reserved for Netscape4, because they know that NN4 is irrelevant, and the hatred has to go somewhere: the least compliant browser out there... IE.
Now, why is IE the least compliant? Because MS doesn't see the need to make it compliant. They have their precious market share, which is all they care about... not the users, not the developers which must coddle to IE because it works the way MS sees fit, not the standards bodies which MS continually ignores while attempting to participate.
The only way to break IE and move to standards is to use them, and explain to users why sites don't work: it's not the site's fault, it's the browser's.
Given all this, most people who have a clue about W3C standards would say you're doing your development backwards. You'd probably save a lot of time if you coded to the standards first, then hacked up the code for IE.