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.
I'm doing web dashboards for 6SIGMA and ISO systems. I'm trying to hammer together OWC, ActiveX, Lotus Domino, Apache, JBoss, mySQL, Flash objects, kettle, jfree reports, and a bunch of other stuff.
If it works in any browser at all I'll call it a sucsess.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
It's very short. Exceptionally short. .. but I may be first to market!
http://www.bitworksmusic.com/
BitWorksMusic.com -- odd tunes for odd times
Obviously you have not had to interact or work with other third party applications. Try having a Siebel app look exactly the same on Firefox. :-\
A lot of these applications use almost entirely ActiveX and simply do not work well with alternate browsers. It simply isn't possible, and sometimes you just have to resort to having the app supported on just one browser.
Then why do companies use them? Legacy.
You see, these apps have been around forever, and people have been using them forever with a lot of investment made into them, and folks aren't ready to just give it all up. Of course, they ignore such things as TCO (e.g. having a Microsoft environment with IE, money spent on security and combating worms etc).
So, the end result is problems like this.
There's a strong correlation between people who adhere to the W3C's specifications and people who separate content from presentation, but that doesn't mean that they are the same thing. <font> and <table> are in the HTML 4 and XHTML 1.0 specifications.
Conflating the two leads to people claiming stupid things, like that they are writing "standard" code because they use CSS, when in fact their code is non-standard and full of hacks.
I know over the past few years "web standards" has become a popular buzzword, but there's a difference between best practices and conformance to particular specifications. Just because it's a good thing, it doesn't mean the specifications require it, and jujst because it's in the specifications, it doesn't mean it's a good thing.
Bogtha Bogtha Bogtha
Look, I failed math three years running in high school, but it still only took me about 1.7 seconds to spot the logical flaws in your equation:
IME, staying away from the perils of complexity is much easier when one focuses on sticking close to the standards, and to avoiding most of the pointy-clicky 'web development' toolkits around. There's simply no substitute for a clean, hand-crafted implementation automated carefully and sanely. It keeps maintenance costs down and makes it possible to scale with far fewer of the headaches associated with proprietary - and constantly, arbitrarily changing - pseudo-standards.
Crumb's Corollary: Never bring a knife to a bun fight.
I develop some pretty interesting apps with ECMA-script and CSS, and my practise is this:
- Write a piece of code with standards in the back of your head, and test it with Firefox. Then retest in Konqueror (I'm an avid KDE-user).
- Code the whole app this way
- Boot into Windows, test with IE7. Not much changes needed, 99% works.
- Fire up IE6. Cry, and regain temper.
- Adjust so that IE6 works, without breaking the original functionality. Don't use browser-checks. They'll bite your ass later.
- Test in Opera. Most just works when it already does in FF and IE6, so no harm there.
- Retest everything cautiously in all five mentioned browsers and adjust as needed. IE7 might pose a problem due to the fixes for IE6.
All in all, the basic coding still is the major part of programming for me. The adjusting for the different browsers is not that much of a hassle.Standards are nice, but when it works with Gecko, IE6, IE7, KHTML and Opera, it's good enough. For basic webpages, Lynx is also a testbed for me (with regard to spiders).
Free beer is never free as in speech. Free speech is always free as in beer.
Let's hold our horses and calm down a bit. You are confusing data with presentation. HTML is for content description, CSS is for presentation. Use the right tool for the job, and you can get the effect you want - without using HTML tables. And you will gain accessibility, maintainability, and so on.
The banners, nav bars, headings etc. that you mention are not tabular data. They do not necessarily have rows and columns. A navigation bar, for example, is typically one-dimensional, not two: it's a list of links - hence current best practice is to represent it in HTML as a list (<ul> or <ol>). Because these things are not tabular data, they should not be represented in tables.
Again, HTML is not a layout language. HTML tables are more like database tables than a grid system; like database tables, the relationship between rows and columns exists regardless of what they look like. The browser chooses how to display that information - typically in a tabular format, by applying CSS. That's right, CSS that specifies the layout, not HTML. You can use <div>s instead of <table>, <tr> and <td> tags and still display your information in a tabular format by applying the correct CSS table properties. These properties are about presentation, they say nothing about the nature of the data.
In your case, the banner should probably be something like <div class="banner">, the headings should be <h2>, <h3> etc. (that's why they're called heading tags), and the columns should probably be <div>s, located correctly with CSS (there are some very clever ways of doing this involving negative margins and the like (see A List Apart), none of which force you to misrepresent your data as tables - though in a few cases, using a table for columns is the most practical solution).
No one is telling you what your web pages should look like. They are, however, recommending the most effective, flexible, accessible, and maintainable ways of getting that look using the tools available. Using tables for layout is seldom any of those things.
Who was the idiot that decided now that we use css for our layouts that tables and such can just be deprecated. Tableless layouts are NOT a good idea, although the need for tables has dropped significantly since the introduction of css.
For example, in the header of my site, I want 3 columns, a left,right, center, with different aligns on each.
The "CSS" solution would look something like this.
<div class="header">
<div style="float:left;text-align:left"> Left Content </div>
<div style="float:right;text-align:right"> Right Content </div>
<div style="text-align:center"> Center </div>
</div>
Now this may not have any tables in it, and produces 3 columns, the float order is odd (if I put the float:right after the center, it'll start on a new line since it's after a non-floating div). Also Floats tend to not resize that well in firefox for some reason, leaving ugly trails that look like dragging around a window on a frozen windows desktop.
Now when I start adding more and more content and fine tuning it in the floating div's, it starts to become a confusing mess and become hard to tweak and manage precisely.
With a table, the same effect is achieved with slightly less code.
<table width="100%"> <tr>
<td align="left"> Left </td>
<td align="center"> Center </td>
<td align="right"> Right </td>
</tr> </table>
Also, lets not forget the fact that my table can be fully styled with css as well. So my point being that don't use div's for a solution where another tag exists to solve your problem.
It's good css practice (not professional practice, educational FOR LEARNING practice) to write a site completely in div or spans, but most these other tags are not going anywhere soon, and provide context for your document, for example, in a layout I'm working on now, I use styled <ol> to achieve the same effect that I would traditionally get from a table. I could also achieve the same effect using a series of divs or with styled tables. Although the <ol> makes the most sense when viewing the source because the nature of the content in it is a list, a series of divs or a table would make it a lot harder to immediately distinguish this list.
Css opens possibility of styling your html in many ways, but I can't emphasize this enough CSS IS NOT XHTML, it does not excuse you from ignoring tags because a div with the proper css can produce the same effect. Just because you can do an entire site with only div tags does not mean you have to.
HTML is there now to provide context to the document, and if something is a list, it should be stored in a <ol> or a <ul>, if something resembles a table, it should use table tags, etc.
The idea is that the implementation of the html and the css should be done in which the html document shows clear context, and the css should be based on that context so that there is a clear separation between data/display. using divs and spans only makes it hard to identify context (aside from the classes your using). And when you spend more time solving a problem with div's that a table would still solve in 10 seconds, then you are wasting your time.
True, but my question has long been: why is CSS not better at layout? Say I want a page with a header, three columns of content, and a footer that gets pushed down according to whichever column has the longest content. That's a very common layout task, and it's dead simple to do with a table, but so difficult with CSS that (the last time I checked) it was considered a difficult problem even for authors of CSS books! (I haven't tried your link to the Holy Grail on A List Apart, but you must admit that a layout solution that relies on negative margins is the very definition of a kludge.)
Don't get me wrong: I love using style sheets, and most of the time I'm grateful for CSS. But I hate it that some important things that were once easy have now become hard, all in the name of avoiding tables.
Q: What does the "B." in Benoit B. Mandelbrot stand for? A: Benoit B. Mandelbrot
I totally agree. I tried to be a CSS-zealot for a while. I even made the mistake of trying to totally avoid tables except for 'tabular data' and I am seriously paying the price for it now in the application I'm working on. It's very tempting to go back and rework it so that I don't have to worry about it any more.
The issue? jQuery. There's a TON of neat things like slide and calendar than simply break my CSS, no matter what I do. If I'd designed more simply, with a well-placed table or 2, then I'd have a great looking interface AND be able to use jQuery's Interface plugins.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
Well the goal of any good developer should be to implement the solution as elegantly and simply as possible. Being a css-zealot is not bad, as long as you don't go out of your way to say "look what css can do". It's about using the right tools for the job at hand.