Slashdot Mirror
Designing With Web Standards
Trent Lucier writes "If you've browsed the web design section of any bookstore lately, you've seen him staring at you. The blue hat. The mustache. The blinding neon background. He's Jeffrey Zeldman, publisher of the influential web development magazine, 'A List Apart' and author of the book Designing With Web Standards (DWWS). The first edition of the DWWS was published in 2003, and now 2006 brings us an updated 2nd edition. In a market flooded with XHTML, CSS, and web standards books, is DWWS 2nd Ed. still relevant?" Read the rest of Trent's review for the answer.
Designing With Web Standards, 2nd Ed.
author
Jeffrey Zeldman
pages
410
publisher
New Riders
rating
8.5
reviewer
Trent Lucier
ISBN
0321385551
summary
Foundations for creating standards-based websites using XHTML and CSS.
DWWS is more of a survey course than a deep dive into a particular topic. In fact, a large part of the book is dedicated to the philosophy of web standards, as opposed to their specific implementation. The reader is given background information on the turbulent early years of the web, when Netscape and Microsoft battled each other with proprietary features, driving coders crazy and sending development costs through the roof. Inconsistent support for HTML, JavaScript and CSS often meant that a single page had to have multiple versions written to support different browsers. Predictably, many companies decided to "standardize" their websites on one browser (usually Internet Explorer), causing much pain for users who wanted or needed to use other programs.
Out of this mess came the web standards movement, whose goal was to encourage browser-agnostic design practices. However, the web standards proponents faced several problems at the outset. "Standards compliant design" was synonymous with "ugly." CSS was a 4-letter word, due to buggy and inconsistent browser support. Additionally, few people understood that standards compliance was a continuum and not an all-or-nothing affair.
Which brings us to Zeldman's book. Part 1 of DWWS explains the concepts above in terms that non-technical people can understand. The book states that it is for "designers, developers, owners, and managers..." Of course, the idea that a non-technical person would choose to read a book on web standards doesn't comply with what I like to call "reality." But tech leads may find some ammunition in these chapters for their arguments with management about the benefits of browser-neutral web design.
XHTML and CSS are the main focus of the second part of the book. Readers without any HTML experience will likely have difficulty following these chapters. Those with some experience will learn to master the DOCTYPE, tame font sizes, and conquer annoying Internet Explorer bugs.
Zeldman is a pragmatist, never forgetting that his readers live in the real world with real limitations. Some developers still have to support older browsers, or integrate with proprietary technologies (ex: Flash and Quicktime). He recommends solutions for these circumstances, letting his audience know the pros and cons of each approach. Early in the book, Zeldman states his motto of "No Rules. No Dogma." The book adheres to that statement, explaining that some standards can be maddeningly vague, or that the XHTML Strict DOCTYPE isn't for everyone.
As always, Internet Explorer 6 requires special attention. The (in)famous CSS box model hack is explained, in which jujitsu-like techniques are used to fix one IE bug (the way width is measured) by exploiting another (broken support for the CSS voice-family rule):
.content
{
width:400px; /* All browsers read this line */
voice-family: "\"}\""; /* IE chokes here and bails out of this block */
voice-family:inherit;
width:300px; /* Other browsers make it to the end and use the correct width */
}
Every time someone codes this, a kitten dies. But it is valid markup, and it is used by many standards supporters. A few references to IE7's improvements are sprinkled here and there, but this book was published before the browser was formally released so don't expect too much info.
One of the hottest topics in CSS is the pure CSS-based layout. Pure CSS layouts usually involve the concept of floating elements and calculating widths. In DWWS, we get a chapter dedicated to the hybrid layout. Hybrid layouts make use of CSS and HTML tables to layout a page, although the table usage is minimized. Zeldman is correct to take this approach, which gives readers practical advice and then lets them decide if they want to move on to more complicated CSS layouts.
The chapter on accessibility is one of the most illuminating. Zeldman has well-reasoned retorts to all the common graphic designer excuses for ignoring accessibility. Accessibility does not mean that a site has to be ugly. Rather, accessibility is something that happens under the hood, in the markup itself. The business case for accessibility is also strongly made. Think you can ignore blind users because your flashy site targets a small, hip audience? Be prepared to get punished by Google, since the GoogleBot is the most powerful blind user on the web ("The Blind Billionaire", as it is called in the book).
A brief chapter is dedicated to DOM-based scripting (aka JavaScript), and the discussion is mostly limited to what scripting can do, and not how to do it. The DOM (Document Object Model) is the model for describing the hierarchy of content on a webpage. Modern techniques like AJAX make extensive use of the intimate relationship between XHTML, CSS, and JavaScript DOM support. However, accessibility, usability, and maintainability are still challenges in the hyper-scripted world of Web 2.0. Zeldman doesn't offer much advice on these topics, but provides a book list for further reading.
I have not read the first edition of DWWS, but the second edition makes it clear where Zeldman has changed tactics and techniques. For example, the image replacement technique described in the first edition wasn't accessible in certain screen readers, so improvements are suggested in the second edition.
Overall, DWWS is a good book for web developers that already know the basics of HTML and CSS, but want to update their 1997 coding techniques. Those new to web design, however, may want to start with a book that is a little more comprehensive. Zeldman does a good job of explaining how to create leaner, lower-cost, and more maintainable web sites. On more than one occasion, I put down this book mid-sentence, loaded up my text editor, and was able to make a quick change to solve a problem that was bugging me. In a book dedicate to making the web designer's life easier, what more can you ask for?
Trent Lucier is a software engineer. His latest experiment is localhost80.com
You can purchase Designing With Web Standards, 2nd Ed. from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
DWWS is more of a survey course than a deep dive into a particular topic. In fact, a large part of the book is dedicated to the philosophy of web standards, as opposed to their specific implementation. The reader is given background information on the turbulent early years of the web, when Netscape and Microsoft battled each other with proprietary features, driving coders crazy and sending development costs through the roof. Inconsistent support for HTML, JavaScript and CSS often meant that a single page had to have multiple versions written to support different browsers. Predictably, many companies decided to "standardize" their websites on one browser (usually Internet Explorer), causing much pain for users who wanted or needed to use other programs.
Out of this mess came the web standards movement, whose goal was to encourage browser-agnostic design practices. However, the web standards proponents faced several problems at the outset. "Standards compliant design" was synonymous with "ugly." CSS was a 4-letter word, due to buggy and inconsistent browser support. Additionally, few people understood that standards compliance was a continuum and not an all-or-nothing affair.
Which brings us to Zeldman's book. Part 1 of DWWS explains the concepts above in terms that non-technical people can understand. The book states that it is for "designers, developers, owners, and managers..." Of course, the idea that a non-technical person would choose to read a book on web standards doesn't comply with what I like to call "reality." But tech leads may find some ammunition in these chapters for their arguments with management about the benefits of browser-neutral web design.
XHTML and CSS are the main focus of the second part of the book. Readers without any HTML experience will likely have difficulty following these chapters. Those with some experience will learn to master the DOCTYPE, tame font sizes, and conquer annoying Internet Explorer bugs.
Zeldman is a pragmatist, never forgetting that his readers live in the real world with real limitations. Some developers still have to support older browsers, or integrate with proprietary technologies (ex: Flash and Quicktime). He recommends solutions for these circumstances, letting his audience know the pros and cons of each approach. Early in the book, Zeldman states his motto of "No Rules. No Dogma." The book adheres to that statement, explaining that some standards can be maddeningly vague, or that the XHTML Strict DOCTYPE isn't for everyone.
As always, Internet Explorer 6 requires special attention. The (in)famous CSS box model hack is explained, in which jujitsu-like techniques are used to fix one IE bug (the way width is measured) by exploiting another (broken support for the CSS voice-family rule):
.content
{
width:400px; /* All browsers read this line */
voice-family: "\"}\""; /* IE chokes here and bails out of this block */
voice-family:inherit;
width:300px; /* Other browsers make it to the end and use the correct width */
}
Every time someone codes this, a kitten dies. But it is valid markup, and it is used by many standards supporters. A few references to IE7's improvements are sprinkled here and there, but this book was published before the browser was formally released so don't expect too much info.
One of the hottest topics in CSS is the pure CSS-based layout. Pure CSS layouts usually involve the concept of floating elements and calculating widths. In DWWS, we get a chapter dedicated to the hybrid layout. Hybrid layouts make use of CSS and HTML tables to layout a page, although the table usage is minimized. Zeldman is correct to take this approach, which gives readers practical advice and then lets them decide if they want to move on to more complicated CSS layouts.
The chapter on accessibility is one of the most illuminating. Zeldman has well-reasoned retorts to all the common graphic designer excuses for ignoring accessibility. Accessibility does not mean that a site has to be ugly. Rather, accessibility is something that happens under the hood, in the markup itself. The business case for accessibility is also strongly made. Think you can ignore blind users because your flashy site targets a small, hip audience? Be prepared to get punished by Google, since the GoogleBot is the most powerful blind user on the web ("The Blind Billionaire", as it is called in the book).
A brief chapter is dedicated to DOM-based scripting (aka JavaScript), and the discussion is mostly limited to what scripting can do, and not how to do it. The DOM (Document Object Model) is the model for describing the hierarchy of content on a webpage. Modern techniques like AJAX make extensive use of the intimate relationship between XHTML, CSS, and JavaScript DOM support. However, accessibility, usability, and maintainability are still challenges in the hyper-scripted world of Web 2.0. Zeldman doesn't offer much advice on these topics, but provides a book list for further reading.
I have not read the first edition of DWWS, but the second edition makes it clear where Zeldman has changed tactics and techniques. For example, the image replacement technique described in the first edition wasn't accessible in certain screen readers, so improvements are suggested in the second edition.
Overall, DWWS is a good book for web developers that already know the basics of HTML and CSS, but want to update their 1997 coding techniques. Those new to web design, however, may want to start with a book that is a little more comprehensive. Zeldman does a good job of explaining how to create leaner, lower-cost, and more maintainable web sites. On more than one occasion, I put down this book mid-sentence, loaded up my text editor, and was able to make a quick change to solve a problem that was bugging me. In a book dedicate to making the web designer's life easier, what more can you ask for?
Trent Lucier is a software engineer. His latest experiment is localhost80.com
You can purchase Designing With Web Standards, 2nd Ed. from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
A book on standards that decries rules and dogma. Only on Slashdot could this garner an 8.5.
It sounds like this should have been two books -- one about the history of web standards, and one about how to design for the web, optionally complying with standards.
Picking and choosing which ones you'll follow is about as useful as just writing what you know will work for everyone, except it's a bigger pain in the ass. At the end, you have the same thing: A website that doesn't actually follow any standard. How much hair you pull out in the process is the only real difference.
Just painful, at least until you get used to it. I'm trying to develop an entire web based (graphical, 2d overhead) MMO, following XHTML 1.1 and CSS standards. PHP and Javascript for life :)
It's never just a game when you're winning. - George Carlin
What a genuinely bizarre thing to say.
... makes updates and general maintenance a pain. We've done a few sites that way and they are the ones I hate working on when [the] client calls with updates, enhancements, etc
CSS
Updates/maintenance is one of CSS's strongest points. Client wants all the links green instead of red? Look in my style.css, change a { color:#f00; } to a { color:#0f0; } - instead of pick through 50 pages looking for every <font> tag inside an <a> tag. Client wants the left hand navigation column to be a bit wider? Look in my style.css, change div#leftnav { width: } to something bigger. As opposed to picking through 50 pages trying to work out whether it's the fourth level of nested <table><tr><td> which controls that, or the fifth level.
If he wanted to complain about CSS designs being less consistent than table based ones I could somewhat understand his point. (Although I'd still say he needs to google the IE box model, take his pick from any one of several very easy solutions (including CSS hacks like the Tantek hack; abandoning padding and using only margins, with extra wrapper divs if necessary; serving different CSS to IE via conditional comments...), and then realise the majority of his layout issues have vanished...)
Then again, judging by this:
versus looking up styles
it sounds like he was just lazy and didn't want to learn something new. Looking up styles? Oh noes. Really, you've only got to do professional CSS-based design work for about a fortnight and you've memorised the 90% of the stuff you need on a regular basis. For the more esoteric bits that you do need to look up, it's not like there isn't a vast amount of CSS reference material just one click away.
Tables don't cause any problems if they're done correctly
Well, apart from the huge nest of tables inside cells inside tables inside cells inside tables being (a) a waste of bandwidth and (b) far harder to write and maintain. And being piss-poor for people browsing with screen readers, and by divorcing content from presentation completely all kinds of interesting microformats / data mining / semantic web type of applications become totally impossible.
Microsoft did start adhering to the standards. They just stopped long before they were done.
.NET 3.0 (a.k.a. WinFX a.k.a .NET 2.0 + Avalon + Indigo etc), XPF and other standards which would've taken decades to produce at W3C.
.NET 3.0 is an amazing achievement and I'm sad to admit that despite Microsoft's ambitions to turn it into a cross-platform environment it may remain mostly a novel (and exciting) way to produce great looking and functional Windows applications.
.NET 3 (and partially with Vista, though it's apparent this is not their final word on what Windows should work like), they are catching up at full speed with the standards, and IE7 is a huge step in the right direction.
They actually *created* a noticeable chunk of said standards.
Microsoft employees were part of the CSS, XML, XHTML creation committees and had significant contributions to those standards.
You can however understand that a commercial company where time is money and money is matter of survival in a market developing with a furious pace would be disappointed at the speed at which W3C works.
IE6 was abandoned for no other reason but the creation of what is today known as
You gotta applaud Microsoft that for all crap they spew at times, they are brave enough to stand on their own versus copy verbatim what their competition produces (no I'm not being sarcastic).
But Microsoft's work is what caused Macromedia (now Adobe) to produce the gem Flex 2, which is viable alternative for web applications running on all major platforms.
Anyway not to get carried away, now that Microsoft have realized their strategy and "vision" with
Their (public domain) extensions to RSS are also creating incredible new ways for people to interact with web content.
Many of the more persistent issues in IE6 aren't due to impelementation of the CSS standard (or lack thereof), but rather of bugs. I mean, sweet baggigty, how on Earth can you predict if IE6 is going to double the margin on a floated element or not? Hell, it's a "here today, gone tomorrow" issue for a full-time web designer.
And don't get me started on the peekaboo bug. That one alone took me a day and a half to figure out. For the most part, IE7 will respect web standards (and hell, even better than Firefox 2 in some places), but for IE6, and parts of IE7, you just need to build a nigh-encyclopedia knowledge of various bugs and workaround.
A List Apart and are fantastic resources for bug hunting
Item 7 was a surprise:
http://www.librarything.com/unsuggester/1426655
Now wash your hands.
When someone makes a site that's IE only, he's not just hurting firefox and opera users. It makes it much more difficult for it to be compatible with future versions of IE. Such short sighted thinking...
Firefox Power http://firefoxpower.blogspot.com/
That's what I used to do too, until I read Zeldman. I loved it. One of the big disadvantages, however, is that you lose the semantics of HTML (such as they are). Those semantics are valuable - for search engines (clean HTML can make a big difference) and for other applications. There aren't a lot of data formats as well-understood and universal as HTML; that's worth taking advantage of. Remember, your HTML is likely to outlast whatever data source you're pulling your content from.
These days I depend on those semantics. I've been doing DOM work with Javascript to add dynamic annotation with margin notes and highlighting to web pages. I need to know the content model so I can determine where I can insert tags to add highlighting (<em> can go in <p> but not in <style>, for example). I locate highlights by counting words, so I need to know where words break. Block-level elements break words, while inline elements don't (so in your example you need a minimum of div, a, and span). I also collect other metadata, like the title and author of the annotated content, and so on. I do that by looking for elements in the document tagged with specific microformat classes.
What are the benefits? Well, if you look at my code, the output of my Javascript or my Atom feed, the information is all meaningful in a standard way. This can reduce or simplify glue code if you need to work with my data - and I think the universal experience with glue code is that although it seems simple and brainless, it gets heavier and heavier until it places serious limits on application complexity. Over time, I hope this kind of standardization can slowly lead to apps and libraries being easier to plug together. The standardization of HTML, and the shared meaning of some of its elements has already proved a huge win on the Web, messy, inconsistent, and broken as it is.
But I'm a geek of simple pleasures. Right now, I'm just thrilled that my transport format I picked - Atom (with embedded HTML) - is machine readable and shows up with sensible formatting in a generic feed reader. (I couldn't afford to use HTML if were a layout language, because then changing the look would break my machine parsing.) It's not rocket science - but that's kind of the point.
Because CSS stands for Cascading Style Sheet; and style and layout are not the same thing. Style is fonts, colours, line spacing and stuff. CSS is great for style, particularly so where you want to apply a single style consistently across many pages. Layout is about how the building blocks of the page hang together. You can do this using CSS, in the same way that you can handle style using html, but it's not ideal (although on balance I'd rather use CSS for layout than html for style). All of the CSS kludges I can think of right off the top of my head relate to problems of layout, rather than style (unless you want to count image-replacement techniques, which I suppose are a sub-set of style, rather than layout).