Summary
I've just finished reading Jeffrey Zeldman's book "Designing with Web Standards" (New Riders 2003), and it has answered a number of questions and dashed a fair number of my hopes for actual standard standards in the near future.

The book was recommended by one of the attendees of the Programming the New Web conference. The promise of web standards seems to be this: you give the right XML tag to force the browser into "Standards compliance mode" mode, then use CSS, and your pages will look the same across all browsers.

This lovely idea got me very excited when I first heard it at the conference, and I have had some success creating pages this way. But I've also found that the promise is far from fulfilled, and achieving pages that just work reasonably across browsers doesn't happen just by adopting XHTML and CSS. Far from it.

Let me first say that I'm mostly amateur when it comes to building web pages. I've created all the pages and markup on my own site, but I don't do it day-in, day-out as a job. In addition, I am empowered to make decisions like "it's too hard to make this layout work across browsers, so I'll change the layout to something that will work more reasonably." Whereas the professional site builder will probably have to make the layout work rather than changing the layout, which could mean some heavy-duty head banging.

Also, I've found the use of CSS to be an interesting and diverting challenge, kind of like doing a jigsaw puzzle is for some people. So I end up spending far too much time just playing with a single page in order to understand the CSS issues and make it come out decently. In my own mind I don't consider this time to be lost, because I can chalk it up to "research," and I believe that what I learn will continue to pay for itself in one form or another over the years.

The upshot is that, with XHTML and CSS, it's now possible to produce documents that work reasonably well across browsers without having to embed all kinds of messy browser-specific code. But the result is a bit like Java: the promise was "write once, run everywhere" and the reality was "write once, test everywhere." And to get things to actually work across browsers, you have to learn the tactics that work the best, and this learning process appears to happen on an individual, trial-and-error level.

I would go further and say that the whole web is a mess. CSS and XHTML are great but it's still "write once, test everywhere" at best. Plus now we have the IE "protected content" issue which makes the visitor click 3 times every time they go to a page that has Javascript on it. So the web is still a mess, but less of a mess -- we've seen definite improvements.

Sometimes it's hard to tell whether it's worse, on a complex layout, to struggle with styles or to use old HTML and try to force everything into place. Because of this, I'd say that web standards haven't lived up to their promise yet. If they ever do, then it should be unquestionably obvious that you should always use XHTML and CSS on all projects.

On that note, despite the CSS goal of eliminating table-based markup, it appears that there are still times when resorting to tables is the best solution, albeit in concert with CSS. One example I encountered was in creating radio buttons with button descriptions that were long enough to wrap. In order to get the descriptions to left-align, I ended up using a table. Despite that, it's clear that the results of occasionally using tables are far cleaner than the old way of using tables everywhere.

Unfortunately, CSS, as I shall describe below, is a mish-mash that requires you to remember lots of special cases. Even though it's significantly less bad than old HTML, it's really unfortunate that they couldn't have gotten in right this time.

The Book

First, some comments about Zeldman's book.

Roughly the first 1/3 of the book is almost a guide for selling web standards to your non-technical manager. If you already buy into the idea of web standards, this can be safely skipped in favor of the second 1/3, which introduces the meat of the issues and how to use the technology -- and how the technology is supposed to work. The last 1/3 of the book goes into all the gotchas about how the technology really works, and a number of workarounds that may be obsolete by now.

Although Designing with Web Standards is an excellent book from the standpoint of content, historical perspective and practical information, it is somewhat dated in the browsers it talks about, but this doesn't really diminish the experience of the book.

What does diminish the experience is an excess of what I'll call the "I'm clever and funny" syndrome that I see in far too many technical books these days (even, unfortunately, in a lot of the newer O'Reilly books). I think it arose from books that were trying to gently prod beginners into learning frightening new technologies, and in those books it served a purpose.

But when you write a book that people want to read for information and you decide that they also want to help you try out your stand-up comedy routines, you are treading on dangerous ground. I would have appreciated a smaller book (believe me, I hope I never publish a 1482 page volume again) that didn't force me to scan for information ("is he saying something useful here, or is he just vamping?"). There are times when Zeldman will go on for a paragraph or two with attempted comical banter that adds absolutely no information, and the reader eventually learns to skip forward when these occur. But it does not serve the reader to force them hunt for information among non-information.

At one point, Zeldman seems to start becoming conscious of this. On page 308: "Gosh, that was quite a sentence. (Must. Delete. Overwrought. Sentence. Before. Manuscript.)" But alas, he and his editor both thought this was so hilarious that they left it in, along with the overwrought sentence. In fact, 5/6th of that whole paragraph was wasted time. (Please. Stop. Drivel.) Because of this, I would guess that the book might lose 1/4 of its pages in the next edition, especially with a better and more aggressive editor, and go from "good with annoyances" to "great."

Many of the browser discussions are dated and he talks a lot about browsers that are probably not used anymore. And although CSS can really reduce the bandwidth needed by your site, he goes a bit far in his zeal for smallness, to the point of making short unreadable URLs (often to load gif files that overwhelm the difference of a few characters in a URL), while at the same time making long, more readable names for styles -- which will be used at least twice, and sometimes many more times. Sometimes his lack of technological understanding shows in other ways; at one point he asserts that Javascript embedded in a page will "run on the user's hard disk."

Even though it (really) needs an update, and you have to wade through a lot of stuff that is no longer relevant along with a lot of mindless drivel that the author and editor should have removed, this is still a valuable book to read. A lot of things became clearer to me, especially about CSS, that the other CSS references I have couldn't seem to convey. And the overall understanding of the issues and the big picture of the state of web standards is invaluable.

CSS Has Plenty of Quirks

Possibly the biggest problem is that CSS features don't apply orthogonally. That is, you can learn a feature that works in one situation, and then assume it should work in another situation, but it doesn't. For example, changing the text size seems like it should apply in all situations, but if you try it in a a:hover style, the text size doesn't change when you hover the mouse over a link. There's nothing like seemingly straightforward rules with lots of exceptions to make an apparently simple system ver complicated.

Not to mention the whole testability issue. No one was thinking about testing when they created HTML, and they didn't seem to think any more about it with CSS.

I'd still like really basic things, like some standard way to include other HTML files, and ways to create the equivalent of functions.

Div and span can produce different behaviors under IE and Firefox -- if you start changing DIVs to SPANs you can find elements jumping to different parts of the pages depending on which browser you're using.

And here's a huge question: why do I have to use DIV and SPAN to delimit styles? Why can I create <MYOWN> tags?

CSSZen Garden pages don't all work with Firefox, and I suspect they don't all work with IE.

The <q> quote tag works with Firefox but not with IE. This produces typographic ("round") quotes.

You can center text, but as far as I can tell there's no CSS way to center any other components. The best I could find is to add 'align="center"' as an attribute of the div tag. If so, it's odd, because you're supposed to be able to do everything with CSS that you formerly used HTML markup for.

In Firefox, you can go to the "Tools" menu and select "Page Info" to see what mode a particular page is rendered in. As far as I know, there's no way to do this in IE.

The CSS2 "Content" tag -- a very good idea, and why did it take them until CSS2 to figure it out? -- is not supported yet in IE. So it's basically useless because they didn't think of it until CSS2.

I've had borders that disappear when going from web view to print. Usually the solution is to add more margin, but you'd think that if it shows up in the browser, it ought to print as well.

I've also had borders appear when some unrelated change happened. I would end up spending a lot of time tracking down where the problem was (in one case it appeared to be a browser bug), and I had to then figure out some workaround, in one case by changing the border so that it was attached to a different style tag.

The real problem I see here is that behavior is not consistent, and often not associated with the style that I change. The application of styles ought to be logical, and yet they aren't because of odd behaviors. And what's worse, it's very difficult to tell whether I'm misusing the styles or whether there's a bug in a browser, or worse -- both.

Here's another one: if you define a style id for the HR tag and give it a left margin and width, it behaves differently between FireFox and IE; it's in noticeably different positions. But if you use a plain HR tag and surround it with a style that has a left margin and width, it behaves the same in both browers. I've been running into issues like this all the time, and I've yet to stumble across any writing about "practices that work." Everyone just seems to treat all approaches as if they will produce the same results.

Positioning can be done in a myriad number of ways, kind of like Perl: "there's more than one way to do it," so you're left wondering what the best way is. Well, for some kinds of positioning you get radically different behaviors between IE and Firefox. The positioned elements will appear in completely different parts of the page.

I ended up having the most success when trying to arrange text blocks across a row by using "align:float" and setting the left-margin for each element. That produced very consistent results between IE and Firefox. But I only got to this by trial and error; all the docs and books that I looked at (except Zeldman's) gave the impression that you could achieve the same results regardless of what technique you used, and none that I saw suggested that "align:float" would give consistent results for positioning.

I'm guessing that, because of the mess of early HTML days, everyone who learns to build pages just goes through this process and figures out the necessary bag of tricks, and so the authors of the books that I perused never thought of saying "here's what it would appear you can do with any technique, but here's the technique that works best." Admittedly that would take a lot more work, and I know whereof I speak when I say I understand how someone would back away from such a task. It's easy to get started on a book, then discover how much work it's really going to be, then look at how much you're really likely to get and decide that it's not worth the extra effort. (Which is why you should never write a book for the money you'll get from the publisher -- in this equation, only the publisher has figured out how to make books a profitable business).

Firefox handles fonts very differently than IE; one example is sizes. You can't make a font any smaller in FireFox than its standard size. So it ignores font sizes like 75% and 0.75em. It also ignores the font size keywords xx-small, x-small and small.

I wonder about web editing systems, such as DreamWeaver and the like. Do they generate web standard code? It seems like it would be much, much easier to create a web editing system that used standards, because the code generation seems like it might be much easer.

Nonetheless, I'm Not Going Back

So the best you can do, without making a complete mess of things trying to make it look identical across browsers, is to get it to look tolerable in multiple browsers. This will often require some compromises.

It's possible to design around issues, usually by simplifying your design (assuming you are in a position to make that choice). However, if I get into a situation that requires anything fancy, at this point I'm not going to try to jump through all the browser hoops; instead I'll build it with Flash using Flex.

Talk Back!

Have an opinion? Readers have already posted 14 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.