Web Design Best Practices: Semantic, Seperate, Sensible

by Shawn Thomas

This is an example of The Right Way to do a few web tricks. It abides by the World Wide Web Consortium (W3C) doctrines of semantic markup and seperation of content, style, and behavior. Following these best practices allows easier maintenance of web content, easier indexing by search agents, and greater accessibility by a wider range of browsing software.


This HTML file contains nothing but the text document and form markup. The document is built up in a structural fashion: it has headers, sections, paragraphs, lists, and so on. Each part is included because it has relevance to the content and interpretation. For presentation, it is layed out and styled according to the CSS file referenced in the document header. Presence or absence of the stylesheet file does not affect usability of this document. These concepts are well known to modern web designers and current design automation software, but now there's a difference.

What is new and now gaining relevance is the third concept concerning the role of behavior in the modern Web. Behavior is the use of a scripting language to affect the user's interaction with a document. Examples are text manipulation, validation of form input, changing stylesheet rules and presentation, loading of external documents, etcetera. Actually, this is an old concept but it's now seen under a new paradigm called "unobtrusive javascript". The form below contains no scripting code to make it do anything; it's just a form in HTML. However, special form behavior can be added by bolting on an external javascript file in the document header. Browsers that can support it will have the advanced behavior. Give it a try.

Text area usability

When the page loads, the script attaches DOM events to the radio controls. Those events (in browsers that support them) control the ability to use the textarea. There are no chunks of inline javascript to mess up the pristine nature of the HTML markup, making the source much easier to maintain. The use of external javascript isn't a new concept; it's been around since the dawn of browser scripting. However, using scripting in a purely unobtrusive way allows designers to start with simple sites and keep them simple enough for any browser.

The concern, now, is to build sites that follow recommended standards closely enough that anyone can access them regardless of what they use. The browser and its capabilities are no longer that important. This point is especially valid now that almost every new cellphone and portable device is able to browse the web; keep it simple, and everyone can read it. All browsers can render the document and its structure; that's layer one. Layer two is the layout and presentation applied by CSS; more browsers support varying levels of this layer. Layer three is the behavior gained from external scripting; some browsers support this, but not all. Avoid putting your site's critical parts behind this layer since not everyone can use it. Offload the real form validation onto your server. Use unordered lists instead of dynamic html to present your site's navigation; you can modify their presentation and behavior later if necessary. Avoid using script-laden dropdown lists as your only method for moving between pages; scriptless browsers and search engines can't use your site.

Keep with the simple ideal of seperating the three layers and all should be well.

Post Script

The form uses a few little-known but increasingly helpful HTML tags. Most immediately useful is the <label> tag on the radio controls. In some browsers it allows the user to click on the text label to toggle the control. It clearly defines a visible name for the control, reducing ambiguity and increasing semantic value. Also nice is the usage of the <fieldset> and <legend> tags; a fieldset is a group of semantically-related form controls and the legend is a textual name for that fieldset.

The defer attribute in the <script> tag is a hint to the browser that the external script does not return any output and that it is safe to defer parsing of the script. This is useful for telling the browser that the external script is not essential for the rendering of the page; if the server is slow in sending the script, the browser is still able to show the page. Using the attribute does not guarantee that the browser will delay parsing and executing the external script (Microsoft Internet Explorer is the only browser that delays execution; most others follow the W3C specification). If you have scripting that relies on the existence of specific document elements (which may not exist yet when the script is loaded) try enclosing that code in a functional block and call it with an onload event handler.

In researching for this page, I discovered that use of the <i> (italics) and <b> (bold) tags is no longer a recommended practice. Their effect is that of presentation only and they have no relevance in the structural layer of pure HTML. They carry no semantic weight and the styling is best served with CSS. What is recommended, however, is to use the <em> tag for text that you would like to emphasize to the reader. This adds weight to the text, makes it important in the context in which it sits. Some browsers display it as italicized text, but its actual presentation may vary. If you would like to strengthen a piece of text to make it important, use the <strong> tag. It may be displayed in a bold typeface, but like <em> its presentation may vary. The jury is still out as to which tag should be used, but follow your gut.