|
|
JANUARY 19, 2004 Web standards: The Good, The Bad, And The Ugly
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.[an error occurred while processing this directive]"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. The bad 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. Prev 1 2 3 Next Related sites: • Creative Mac • Digital Media Designer • Digital Producer • Digital Webcast • The WWUG Related forums: [an error occurred while processing this directive] 
|