Zeldman’s ‘Three-Legged Stool’ Approach to Web Standards
Introduction
Anyone who’s spent time in web design/development, and who belives in the magical (some would say ‘fairie-induced’) nature of web standards, knows about Jeffrey Zeldman. As one of the original standardistas, he’s given much thought to good content and correct markup.
The three-legged stool approach goes like this: First, you write your content. This is the stuff that the people are coming to your site to visit. Then, you support that content base with the three legs: Use HTML to structurize your content, to differentiate between emphases, titles, lists, paragraphs, and other important indicators of the content’s purpose. Use CSS to target each element and give your page its presentation with colour, depth, shape, layout, and uncannily-fabulous taste. Finally, use JavaScript to add behaviour to the site, so that it reacts dynamically to the needs of its users.
So there’s your introduction. It’s a well-thought-out approach to building your websites in a modular fashion, so that the pieces are easy to update and can be used across pages to reduce bandwidth.
This separation results in websites that are adaptable across many different browsers, platforms, and devices.
And then it gets tricky
There is no such thing as black or white. Using the <em> element to mark up emphases automatically styles it, as with most other elements. Some CSS pseudo-selectors change the page based on user input, as scripts should. JavaScript can very well do anything, which puts developers at risk of using it to set things that should have gone into HTML or CSS.
Where are the lines? Does it matter?
Practical Examples
In the HTML5 Working Group, there’s been a lot of fuss over some of the new elements being thought up. Accordion-style content? Progress bars? Calendar widgets? “Don’t those belong in jQuery?”
In CSS3, there’s also a bit of hubbub over the animations and transformations. When you can effectively code a movie using only CSS and a bit of HTML, are you going too far?
My Own Thoughts
Obviously, it would be snobbish to ban any cross-over between the three pillars. The question, then, becomes “why do we cross?” and “how much can we cross?”
Why use features in an unrelated stool-leg? Why, indeed. Hover effects or the like could be triggered with script, except that takes programming skill. The greatest argument I can think off the top of my head is that CSS is much simpler, in both syntax and complexity. Making simple animation loops is far easier in CSS3 than it is with JavaScript.
As well, those seemingly-action-based animations or hover or transformations may be entirely presentational, so it makes sense to put them in CSS.
When you get right down to it, the question is one of intent: Why is this element doing that thing? “Because it looks pretty.” Or, more realistically, “Because it fulfills a design requirement.”
So how much can we cross the streams? As designers and developers, it really isn’t up to us. Use class changes in your JavaScript to change the styles of elements, and use :hover if it fulfills an objective, but there’s little else to keep in mind. For the working groups, though, it’s an entirely different question.
Really, it comes back to the question of needs and uses. Canvas is a prime example; it’s only a big graphic, which makes it presentational, but it’ll likely hold valuable content, so it’s a main part of your page, but it’s implemented entirely with JavaScript.
And you can do so much with it.
Conclusion
We should be very careful when adding new mixes to the specification, but there’s no reason to ban that outright. Meanwhile, developers need only keep mindful of their reasons for implementing things the way they are.
