The Web is a platform. For publishing, for interaction, for information mining, for entertainment, for commerce, for fun. Whatever form it takes this platform we call the Web is underpinned with standards, the 3 legs of the stool. And those cross-supports that keep the legs from collapsing and flying away from each other.
Here we'll take a look at each leg, why it is important, and some resources to help you apply these standards to your web design, whether it is a blog, a pro bono site or your job.
XHTML, the first leg
In order for a web site to work you need to start with a well structured document. XHTML provides that structure. And the good news about XHTML is that it can be read and understood by browsers back before even NN4.
What is XHTML?
XHTML is a reformulation of HTML in XML. It is much more structured and less tolerant of invalid code. In fact, if you write valid XHTML, the browsers will assume you know what you are doing, and render things according to their strictest understanding of the standards.
It’s not as scary as it sounds. And since it’s really still HTML at its heart, it isn’t that hard to adapt to. Rather than rehash the helpful sites that are already out there, I’ll point you to them and let you discover just how easy it really is.
Jeffrey Zeldman has written an excellent article at A List Apart that will show you how to convert your HTML documents (or workflow) into XHTML. Also at A List Apart, Carrie Bickner shows you how to make Dreamweaver 4 output valid XHTML. It’s worth a look even if you are using Dreamweaver MX. And, for a good overview of how XHTML fits into a site’s style guide, check out the New York Public Library’s Style Guide section on XHTML.
Strict vs. Quirks
As I alluded to earlier, the way a web page is coded will cause the latest browsers to implement it in one of two (or three) modes. If the browser contains a fully qualified Doctype, then browsers will use Strict or Standards mode, following the W3C’s recommendations as fully as they are able. If not, then, depending on the browser, at some point it will enter Quirks mode. Each browser has created its own set of rules for invoking these modes (and what they mean), and they will affect the way your carefully crafted CSS is interpreted.
Cascading Style Sheets, the second leg
Hardcore standards geeks will tell you that as you mark up your page, you should not worry about how the XHTML will be laid out and styled in the browser; a logical structure is more important, and the style sheet will take care of making everything look nice. This is called separating the content/structure from the style. And this is usually interpreted to mean that you should not use tables to lay out your page.
Hardcore standards geeks also use the latest nightly build of Mozilla (or some other gecko based variant) that can handle all the CSS needed to lay out a page without tables. Or they don’t really care what the page looks like anyway.
You are probably not a hardcore standards geek. Even if you are, your boss or client most certainly isn’t. In fact you likely have (had) a creative brief requiring your site to look the same in Netscape 4, the latest version of Mozilla, and Internet Explorer for Windows. You might want to use a basic table for layout in order to meet this requirement.
And you can. Despite what hardcore standards geeks might say, you can use a table for layout and still create valid XHTML. But if you’d rather not, there are plenty of sites out there to help you use CSS only for layout. Even some that will work in Netscape 4.
CSS and NN4
My blog is my playground. It doesn’t work right in Opera, or IE6 for Windows. IE5 Mac gets it almost right, and Gecko based browsers such as Netscape 7, Mozilla and Chimera do the best job. But I don’t really care that much since the content is available to anyone who cares to stop by, including those who use version 4.x of Netscape.
On the other hand, at work I have to cater to Netscape 4 users. And most of them are using it on a Unix box. So, I have a number of tricks that I have developed and honed for these users. Many of these I share at Real World Style. But there are some things that NN4 just cannot handle. Like my blog, for instance. Fortunately there are ways to hide CSS from NN4 and other browsers.
Hiding CSS from browsers
Johannes Koch has put together a great resource outlining ways to hide CSS from browsers. Kevin Smith has also collated a number of CSS Filters, as he calls them, that allow you to hide problematic CSS from specific browsers.
NN4 specific issues
Now that you know how to hide CSS from NN4, you’ll need to know what CSS to hide. Perhaps easier is laying out what works with NN4. Bob Sawyer has kindly outlined the CSS that NN4 can handle. Trying anything else with this years old browser is risky.
What about other browsers?
You might also be interested in taking a look at a couple of CSS browser compatibility charts. One from WestCiv and the other from Web Review. These charts can be quite helpful in deciding what level of support you want to provide various browsers.
The above charts pretty much cover CSS1. CSS2 is a whole ‘nother world. There are so many interactions between CSS rules that can take place now that it becomes difficult to create nice, neat charts. So Big John has stepped in and created a CSS bug ring - a loosely organized group of web designers who document and demonstrate a variety of bugs. These sites are a good place to check when you encounter strange behavior in a given browser. And Owen Briggs presents the CSS Panic Guide—when you don’t know where else to turn...
As you begin to feel more comfortable with the idea of XHTML for structure and CSS for style, you might want to read this blog entry by Tantek Çelik, author of IE5 the Tasman rendering engine used in the Mac version of Internet Explorer (version 5.x). In it he shows you how to tie CSS and (X)HTML together in a meaningful and richly semantic way. See also Environmental Style at Real World Style for more on the subject...
Accessibility, the third leg
Many reading this are probably surprised that I am calling Accessibility the third leg, after XHTML and CSS. You probably had something else in mind, but I’ll get to that later.
Not just a good idea
Accessibility is now the law for a great many sites. The courts are still determining exactly how the law will affect general web sites, but it is fairly certain that if you would be required to have a wheelchair accessible physical presence, your internet presence is going to have to be accessible as well.
This is a good thing. If your site is more accessible to those with disabilities, it is really more accessible to everyone. And the truth is that making your site more accessible isn’t all that difficult to work into your current design flow. The key is to do it up front rather than try to retrofit it later.
But How?
Good news—there are resources that will help. Ian Lloyd’s accessify.com keeps tabs on accessibility in the news and offers some excellent tools for helping you create accessible tables, forms and more.
Mark Pilgrim’s Dive Into Accessibility originally ran as a 30 day tutorial on creating a more accessible weblog. Now at it’s own domain, it is the most comprehensive and practical accessibility tutorial that I am aware of on the Web.
WebAIM is chock full of resources for the web designer who wants to do right by accessibility. And then there are Bobby and the WAVE, accessibility validators that will help you find potential problem areas as you are creating your sites.
More
And you don’t want to miss the Slashdot interview with Joe Clark. Joe has written a critically acclaimed book on the subject, and is serializing it on the web, adding a chapter each month. We should see chapter 2 in January...
The DOM, holding it all together
Many of you probably thought that this should be the third leg of the stool. And there are good arguments for this. I prefer to think of the DOM as the cross pieces between the legs that keep them from flying out away from each other, and the stool from collapsing.
The Document Object Model
More than just an outline of your page, the DOM is a Model of the Document that is used to create the web page. Each element, or Object on your page is modelled, typically in a tree that examines the relationships between these objects. It identifies these relationships in terms of ancestry, parent-child, and siblings. You can get a sense of it in Mozilla by using it’s built in DOM inspector.
This is much more powerful than a simple outline, as each element can be described, identified and manipulated. The DOM works with correctly structured XHTML and valid CSS rules to render the page. But you can also use scripting to manipulate any element on the page, changing it, adding or subtracting content and/or style, as long as it all remains valid.
What about accessibility?
The DOM allows a program to quickly find all the links in a page, or all the level 1 headings. It can extract all the lists, or even all the ordered lists. It can build a simple outline of the page. As far as I know current accessibility tools, such as screen readers, do not take advantage of the DOM to get these types of information, but they could.
Many sites feature DOM based style sheet switchers that allow you to choose a site wide style that fits your needs as a user. Some of these switchers allow for completely different styles to be applied to a site, and others simply offer the ability to change your font size.
So you can see that the DOM is really not a supporting leg, but what ties all the other technologies together.
From the horse’s mouth
I decided to wait until the end of the article to link to the W3C pages on each of these topics, as they can be a bit arcane. I still don’t have my mind wrapped completely around the idea of the DOM much beyond what I have written here. So I offer the following links for those who want to get it from the folks that create the specifications:
Validate!
I can’t emphasize enough the importance of properly marked up pages and style sheets, and while we’re at it, correctly implemented accessibility hooks. So I might as well link to the validators again:
- (X)HTML Validator
- CSS Validator
- Bobby, accessibility validator
- WAVE, accessibility validator
Email lists
Often better than books, email lists can be invaluable resources when you find yourself up against a difficult task. Here are the best I have found covering XHTML, CSS and Accessibility.
- In general
- Webdesign-L is an advanced, high traffic list, covering all aspects of web design. At any given time there may be threads on topics as diverse as back end programming (PHP, asp, perl, java, and others), CSS, and the vagaries of the XHTML 2.0 spec, not to mention a site check request or three. If that sounds exciting to you, you are probably already a member. If you don’t think you can handle the extra 30-70 emails a day, sign up for the digest...
- Arbiters of Style
- CSS-discuss has just found a new home, but that hasn’t slowed it down any. This is another high traffic list, but devoted entirely to the practicalities of CSS. Moderated by none other than Eric Meyer, this is a very valuable tool for anyone who has decided to jump into the pool known as table free design. Again, consider the digest if you aren’t accustomed to an extra 30-70 emails in your inbox each day...
- Keeping accessibility in mind
- A friendly group of folks who are dealing with accessibility on a day to day basis, and are willing to share what they know. The Web Accessibility Forum is not nearly as prolific as the other two I mentioned, but they are no less helpful...
Thanks for reading
I know there are a lot of words here; if you have made it this far, I thank you. And I hope that you have been rewarded for your efforts by finding something of value within all these words. A link, a bit of encouragement to do the right thing, or even a new resource or two.