JANUARY 19, 2004
Web standards: The Good, The Bad, And The Ugly
And why designers should ultimately care
by Kevin Schmitt
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?[an error occurred while processing this directive]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.
1 2 3 Next
Related sites: Creative Mac Digital Media Designer Digital Producer Digital Webcast The WWUG
[an error occurred while processing this directive]