Filed under Opinion on Monday, January 19, 2004
In retrospect, I really have to thank both Microsoft and Netscape for their little pissing contest known as the "browser wars." Because of their antics, I may have never gotten fed up with Web design as a primary vocation and, consequently, might never have embraced motion graphics, compositing, 3D animation, and the various other disciplines I'm fortunate enough to make a living doing today. And while I never abandoned Web design entirely, it's been a pretty small part of my professional existence for almost six years now. So when I recently started to think about redesigning my own Web site (having made the decision to not do a Flash-only site this time), my desire to avoid the HTML hell of the past led me to the brave new (to me, anyway) world of Web standards.
I had a bona fide, genuine, seething hatred for Web design by the time I decided to move on (circa 1998), and for good reason. Web design, back in those days, had very little to do with actual design. Compromise, frustration, and endless trial-and-error were the status quo, and once I found myself spending a large portion of most projects in a freaking text editor, it wasn't a big mental leap to conclude that something was most definitely not right. Sound familiar?
Well, even as creative types were stuck in the trenches in mostly futile attempts to produce designs that both Navigator and IE could live with, an effort was already underway to heal the situation. Enter the Web Standards Project, which was (and still is) a grassroots organization founded in 1998 to ensure that major browsers supported a common set of basic, open Web technologies (transitional or strict XHTML, XML, CSS, DOM scripting, etc.) as recommended by the World Wide Web Consortium. The overall gist, of course, is that no one entity (*cough* Microsoft *cough*) could ever have the ability to co-opt the Web if enough browsers and, more importantly, Web designers and developers implemented standards-based Web technologies into their sites.
Fast forward to 2004, and by pretty much any objective measure, the Web Standards Project has been wildly successful. Every major browser, including Internet Explorer, is today compliant with current Web standards (to varying degrees). What's more, leading tools like Dreamweaver and GoLive have been revised in recent versions to fully support these standards. And for the purposes of this discussion, the bottom line (although not real apparent from my buildup to this point) is that the Web Standards Project has re-introduced the long-lost concept of design back into Web design. So, with that in mind, I give you the good, the bad, and the ugly (as the title of this piece so helpfully suggested) of Web standards, as I found through my own research on the subject that culminated in the designing and building of my own site to standards. And while standards purists may have a field day with what my concept of Web standards are and even if I "did it right," I think my experience here might resonate with some of you who may have been in similar situations over the years.
I'm going to come right out and say that overall, the good definitely outweighs both the bad and the ugly in the case of Web standards, but it did take a while to come to that realization. More on that later, though. There are a few big, big things in the "good" category which, once I figured things out, definitely changed the way I approach Web design (for the better, of course):
Real separation of content from design. I've used CSS for several years now, though I (naively) limited its use to controlling font faces, sizes, and colors. CSS (for the unfamiliar, Cascading Style Sheets) is a big part of Web standards, and once you branch out beyond the fonts, CSS is truly a godsend in terms of controlling every aspect of how your site looks, from fonts to page background colors to border thickness and so on. This means that you quite literally do not have to include a single line of code that specifically governs how a site looks, as CSS is flexible enough to be able to override not only regular HTML tags, but can also create specific instances (through classes) that affect small parts of pages. With the proper planning, a complete site redesign is entirely possible through simply modifying a CSS document, while all of your HTML pages and the content within remain blissfully untouched. No more global search and replace, no more broken tags, no fuss, no muss. For an example of this in action, head over to the CSS Zen Garden and see how different stylesheets can radically alter how a page looks without touching the underlying HTML.
Of course, CSS itself is a huge topic, and tapping into its potential beyond simple font stylings is a major part of adopting Web standards. The venerable A List Apart site has a lot of helpful tutorials to get you started, and, as always, Google is your friend. Once you're up and running, I also recommend picking up a copy of Eric Meyer's CSS Pocket Reference (O'Reilly and Associates, 2001), as it's cheap (about US$10), thorough, and, when you get right down to it, there's nothing like an actual book at your side.
Simple, clean markup. This one appealed to me, as some of the table-ridden HTML monstrosities I've seen (and many times created) in my time definitely fall out of the realm of "human readable." I even remember times that I had to remove all carriage returns and other whitespace from certain designs just to ensure Navigator and IE wouldn't let adjacent images drift apart, resulting in some really nasty code to have to pick through later. Ugh. However, I digress. Ideally, I enjoy using nothing more than Photoshop and a text editor to build sites, rather than a WYSIWYG site building program, so the fewer unnecessary tags are around to gum up the works the better. Using Web standards is a pretty good way to cut down on some of the bloat, more so the further you're willing to take your site into the standards realm. As you venture into XHTML transitional and eventually (maybe, someday) to XHTML strict markup, you'll find that you're offloading a lot of stuff to the CSS documents linked to your pages. You can even rid yourself of all those nasty table tags as well (see the next "good" point later), which really cleans things up.
As an aside, don't worry too much if you don't know what XHTML is (strict or transitional). Admittedly, I'm a little fuzzy myself. As usual, I've taken the narrow view of what this means to me rather than what this means in general, and from that perspective, XHTML is just the evolution of HTML to be a little more structured. For example, "open" tags (such as the the <br> tag in HTML) are replaced in XHTML as self-closing tags (like <br />). There are also defined ways of declaring your document (the stuff that's supposed to be at the tippy-top of every page), and a few other structural items. It's mostly to get all browsers to be less lenient on what will be rendered correctly and incorrectly by following the standard for HTML formatting, rather than an interpretation of the standard. This might seem like a counterintuitive goal, but if you're already buddy-buddy with HTML, trust me, the conversion to thinking in terms of XHTML is not a large leap by any means. The end result of coding to standards is that you can typically cut down on a lot of the bloat and confusion in your HTML pages, which, for me, means less time spent in the text editor. And that's definitely a plus.
Not a table tag in sight. If you're going to do something, why not go all the way, right? One of the main selling points of using standards for me was that the days of using HTML tables as layout objects are over. Of course, table tags are still useful for actual tabular content (gasp!), but using DIV tags coupled with CSS gives you the ability to lay out things with actual X and Y positioning, which can dramatically reduce the complexity of the HTML in your page. Naturally, getting out of the table state of mind is probably the hardest ingrained habit to overcome, so even the standards bearers themselves suggest, however grudgingly, that simple tables for things like multi-column layouts are still OK. So don't feel like you need to go whole-hog right away, like I did. I'm just compulsive and knowing that there were unnecessary table tags when there didn't have to be any at all would have really bugged me. It's not you, it's me.
"Nonlinear" markup.Using DIV tags (ID'd appropriately, of course) combined with CSS gives you the ability to place content areas where you want them not only visually on your page, but in the underlying HTML as well. Let's say that your site navigation bar "lives" in a column at the right side of your pages. In the old days, using tables, these elements would necessarily appear at or near the very end of your page's code (generally speaking), or else they wouldn't show up where you wanted when rendered in a browser. Using standards-based markup, you can place these elements inside of DIV tags and have them as the page's very first HTML elements instead of the last. Why would you want to do this? Well, as more and more users start to venture online using phones and PDAs and such, you'll still be ensuring that your pages will degrade gracefully for browsers that don't support stylesheets. By the same token, you might have DIVs that hold purely decorative items, which you can place at the bottom of your code so it won't get in the way of the "real" content. The bottom line is that you can structure the underlying code however you like so your rendered pages will be useful to a larger group of users, not just those with the latest and greatest.
Browser consistency. Now that the Web Standards Project has been successful in getting the word out to all the major browser makers, designing to standards takes a LOT of the guesswork out of how your pages will render. Sure, there are little inconsistencies with how different browsers handle various snippets of code, but once you get the hang of planning for a standards-based design, there are very few surprises once you preview your site in a browser.
Unfortunately, all is not Barq's and Kit Kats in Standardsville. However, of the few things that are "bad" (at least by my definition), none are showstoppers. Rather, outlining the bad is more a chance for me to urge caution, and, more importantly, patience if you happen to be trying standards out for the first time. So, without further ado, the bad:
It's entirely possible to exchange table hell for DIV hell. The DIV tag is vital with standards-based markup, but it's very easy to just throw DIV tags around every other word all willy-nilly. Just remember that the DIV tag is an organizer and not a rendered tag, which is something I wish I had hit on earlier in my own experiments. Ultimately, I came to think of the HTML page as a filing cabinet, and the DIV tag as a folder within. Come up with organizational "folders" for your content (navigation, body text, footer, whatever), and surround these content areas with DIV tags. If you need sub-DIVs on top of that, so be it. But it really helps to consolidate as much as possible to avoid pages that can become just as bloated and hard to read as older, table-heavy pages.
"Pixel accurate" isn't so accurate. One of the big myths about CSS layout is that it's "pixel accurate," meaning that you can just place things precisely and they'll be laid out on the page as if you were using a DTP program. In reality, the way various browsers render pages, even while conforming to standards, differs ever-so-slightly. To put it bluntly, you can't rely on things showing up exact-actly where you tell your CSS to put them, as there's quite often a small shift when viewed in different browsers.
In practice, this so-called pixel accuracy was one of the major obstacles I had to overcome. More often than not, you're not going to be able to squeeze things together that actually have to seamlessly meet the way a fixed table allows you to. It's one of those design compromises that I hated so much from the old days, and truthfully, almost led me to bag the whole thing. However, after I calmed down a bit, it just takes a bit of planning to account for this minor setback. Give your designs a little bit of white space, padding, or whatever to gracefully handle the slight pixel shifts different browsers present, especially when dealing with fonts. This limitation, such as it is, is one of the things that's the "cost of doing business" when dealing with Web standards.
No transparent PNG support in IE for Windows. Still. Dammit. PNG is the current standard for Web images as recommended by the W3C and, naturally, as such is fully endorsed by the Web Standards Project. So it really bites the big one that Microsoft hasn't fully implemented PNG support into IE. Specifically, PNGs with alpha channels aren't allowed. Every other modern browser lets you use PNGs with alphas, and MS's omission is the logical primary reason why the Web is still littered with the ancient GIF and JPEG image formats.
For example, on my own site, each section has a different dominant color, with a slightly screened logo image placed within the colored area. It would have been great to have a single, semi-transparent PNG file that blended itself into whatever background color was present on the fly, but I figured it would be a bad call to do that considering that IE has 95% (or whatever) of the browser market, and IE doesn't support PNG files with alpha channels. So there are five versions of my logo that get loaded at one point or another. Wasteful? Sure. Avoidable? Absolutely? Ticked? You bet. Thanks, MS!
While the good is very good, and the bad is even tolerable, there are a couple of uglies to throw into the mix -- wild cards that can either be ignored or fretted about, depending on your situation:
CSS is cool, but patience is required. CSS, for all its potential, requires a sometimes unholy amount of tweaking to make things appear as they should across all browsers. So much so at times that I was having some serious flashbacks to the bad old days of the browser wars, when everything would look right in one browser and be horribly broken in another. Fix, test, re-fix, re-test, lather, rinse, repeat. It's very easy to repeat this bastardized cycle, at least initially, with CSS. Some browsers have different levels of support with some CSS properties, and I found while getting my feet wet that trial and error was the rule, and not the exception, to getting things looking right in every modern browser. I even needed a Macintosh IE 5-only hack to get the navigation positioning correct (the nav elements were formed from a simple list, rollovers and all) to make IE on the Mac play along with IE Win, Mozilla, and Opera. Odd. Expect a lot of initial frustration as you learn which properties to avoid.
Many options and no "right" answers. What may be daunting to some is that Web standards, when you get right down to it, is a concept more than anything else. Sure, there are a set of technologies that constitute the standards, but you can mix and match on the fly with existing methods. Ultimately, the choice is up to you, the designer, as to how loosely or strictly to implement available standards, and it's quite possible to come up with something that embodies the worst parts of the old and the new. So just be warned that standards are a sliding scale, with lots of built in tolerance for legacy stuff present in various browsers. I'd recommend on new projects going as much as possible with a standards-based design, and if you can't, stick with what you know. Save your standards experiment for a project that can best take advantage of what standards have to offer and start your journey from there. Once you're comfortable with standards, though, you'll likely find yourself backtracking to past projects and retrofitting them, at least in your head.
MS could spoil the party at any time. The elephant in the room, as usual, is Microsoft. They've played pretty nice with all these adorable little standards so far, but they can just take their ball and go home if the whim grabs them. Of course, the more designers and developers code to standards, and the more tools take advantage of them, the less say Microsoft may ultimately have. So the race is definitely on.
I'll go with the television analogy for this one. The broadcast industry is based on standards. In North America, we have NTSC. Most of Europe is on PAL. Other parts of the world use one or the other, and there's even SECAM thrown into the mix. All, however, are a set of rules and guidelines for creating broadcast-ready content. Many, many manufacturers create compatible products for both the creation and the viewing of this content, because standards exist that everyone has agreed on. Sure, the industry is shifting towards HDTV, but there are standards for that too, and at the end of that transition, there will be many manufacturers still creating compatible products for the creation and viewing of HDTV content. Just as you wouldn't want to have to go to a single company for tools to produce and view broadcast programs, you ideally wouldn't want to be locked into a single source to create and view Web content. Having viable Web standards ensures that there are choices in how you produce and view Web sites. For the designer, choice at the production end is a great thing. You want to use a text editor? Fine. A specialized CSS generator? Great. A WYSIWYG site building tool? Go for it. And you'll likely have your choice of software developers as well. Same on the browser end. That's what Web standards are good for, and why you should at least give an effort to learn how to use them. Just think about the alternative.
Another big reason designers should care is because design is a part of the process again. Coding to standards means true separation of design and content, letting the development folk work on the back end while you use CSS to control how things look on the front end. This becomes especially important when you're dealing with huge sites with thousands upon thousands of pages, and you can spend your time working on the design of a site without getting bogged down into the minutia of tag replacement just to implement a fresh look.
As for me, my first real foray into the world of Web standards will not be an isolated one, as I've found that whatever problems exist with standards-based markup are far overshadowed by the problems it solved. And while there were some definite fits and starts in terms of re-training my brain to work within the standards model, in the end, I was able to build a small site that didn't compromise on my initial Photoshop mockup, validated to the W3C's XHTML transitional specs, doesn't contain a single table tag, and (most importantly) is very simple to update and manage. Now, I know that this entire diatribe was borne of a single project, but at least the project in question was complete enough to give me an idea of whether I could even be "wired" correctly to undertake such a fundamental shift to the way I approach Web design (infrequent as it may be) from here on out. Web design may never be a true love of mine, but with Web standards it's a much, much more tolerable (and, at times, even enjoyable) process than it was in the bad old days of the browser wars. And that's all I ever could have hoped for.