A four-level model for web pages

On this page I propose a model for structuring complex web pages in a manner that makes them more robust, more accessible and more maintainable than the majority of pages available on the Web today.

Introduction

Structure models seem popular in IT, especially three-level models – just as three-letter abbreviations are. The three-level model for applications (database, business logic, presentation) is well known, and also its near-relative, the three-level model for web applications (model, view, controller).

Web pages would also benefit from a more structured approach. Most emphasis on web design in recent years seems to have been on the server side, with the client side rather neglected. The result is an enormous number of badly-structured pages, which are hard to read – or even totally unreadable – for people whose situation (hardware, software, browser settings, eyesight or other physical condition) differs from that of the author.

Advice on points of detail (such as my page on defining font sizes) can help with this. But to address the problem properly, one needs also to look at the overall structure of a web page.

Here a structure with four levels is proposed. The model is primarily conceptual, to help you structure your thoughts on how to put a complex page together. However it also provides some practical assistance for implementation.

The perils of lack of structure

As I point out in my essay The Essence of the Web the whole idea of the Web is to be able to support different types of computer, running different browsers, and used by people of different capabilities and preferences. If pages are thrown together in an unstructured fashion, it is highly likely that one will end up with a page which only works on computers very similar to ones own.

Unfortunately some (even most) web-authoring tools encourage an unstructured approach. Text may for example end up being written from Javascript or hidden in Flash. Readers who do not have Javascript/Flash (or normally have them disabled – there are a number of good reasons for disabling Javascript) are quite unnecessarily blocked from reading the site at all.

It is often said that it costs lots of money to support different browsers and platforms. This is in principle not true. But it can be true if the page is thrown together in an unstructured fashion, and cross-browser issues are crudely addressed by brute-force testing until no more problems can be found. In a structured, standards-oriented approach however, it costs scarcely more effort to support all decent browsers than it does to support a couple of the commonest browsers.

Furthermore a structured approach means that a sophisticated version of a page can be presented to readers who have all the latest bells and whistles at their command, while ensuring that readers with more limited platforms can still read the page.

Note that it can indeed be difficult and expensive to support buggy browsers. This is perhaps the origin of the misconception: authors are so used to struggling with such browsers that the whole concept of standards compliance hasn’t yet sunk in. How far one goes in supporting bug-ridden browsers is a matter of judgement, and not an issue I cover on this page.

Separate content from presentation

Presentation
Content

The first key step is separation of content from presentation.

The obvious reason for making this distinction is that it is the content of your site that matters. (Isn’t it? Or does your organisation wish to be known as a hot-air organisation with no real content?) If the reader is unable to appreciate the presentation for some reason, you probably still want him to be able to get to the information on your site.

There are numerous circumstances where this may apply: for example a blind person using a screen reader or Braille pad, a poorly sighted person requiring large black-on-white letters, or someone with a small-screen device (web-enabled telephone etc).

Alternative content

The next step is to consider alternative types of content.

Most pages consist of text and images. The text, delivered as HTML, is no problem – everyone can read that in one way or another. But what about the images? What happens when a reader cannot see the images – maybe a blind person using a Braille pad, or just someone with a slow connection who has switched images off for speed.

If a site is intrinsically visual (e.g. an art site), then there is not much you can do. But in many cases the situation can be adequately addressed by providing appropriate alternative text. See my page the ALT attribute in HTML. The ALT attribute provides alternative content if images cannot be rendered.

Presentation
Content	Special plug-ins
	Video
	Images
	Text in HTML

But there may be more levels possible. Consider a “virtual reality” tour around the Grand Palace in Bangkok, which needs special hardware and software to experience. Can this be incorporated in a web page? By all means. But, recognising that few people will have the needed hardware and software, it will be necessary to have a fall-back to a normal video. And given that most web users have a connection that makes downloading video a time-consuming matter, it would be very sensible to have a further fall-back to still photographs of the Palace. And it would be a nice gesture to blind users, or users of a low-spec computer, to provide a textual description as well.

Thus it is possible to have a hierarchy of content types, each one being a fall-back if the level above is unavailable.

Although the above hierarchy is a logically correct way of expressing the situation, the bottommost layer – text/HTML – is somewhat distinct, because it is the one layer that one can rely on every reader being able to access, regardless of the browsing situation. It therefore makes sense to split this off as a separate layer. (Note that when I state HTML, this is not meant to exclude XHTML.)

Splitting presentation from decoration

The last step is to separate presentation from decoration. By presentation I mean passive mark-up indicating to the browser how the page is to be presented, plus passive presentational elements – i.e. images. For most practical purposes “passive mark-up” here means CSS.

By decoration I mean all dynamic aspects of the page which are not part of the intrinsic content: these are most commonly implemented in Javascript, Flash and Java.

Note that I also include as presentation all non-content images. These are widely referred to as “decorative” images, so there is admittedly some risk of confusion.

Level		Examples
4.	Decoration	Java	Flash	Script
3.	Presentation	CSS / non-content images
2.	Non-textual content	Special plug-ins
		Video
		Images
1.	Textual content	Text in HTML

This gives us the complete model, illustrated here.

The reasons for making this final distinction are as follows:

1. Most site authors will wish to specify some presentation, rather than leave it entirely to the browser-default presentation. Decoration is however very much optional: one can produce a perfectly good site with no decoration at all.
2. Almost all graphical browsers can support CSS, it has no security issues, and users do not often disable it. As mentioned above, many readers will not see some or all of the decoration.
3. The most important point is that if the reader has no CSS, he will automatically get a readable presentation (unless the author has gone out of his way to prevent it). This is not true of dynamic decoration.
4. It also worthy of consideration that CSS and the main image formats are defined in an open standard; decoration is frequently implemented in proprietary formats. (JPG and PNG images are open; the GIF patent expires shortly).

Some effects can be implemented either in CSS or in dynamic decoration. For the above reasons, and particularly the second one, CSS is the preferred method in these cases.

To clarify one point: “decoration” may include any non-essential aspects on the page, including some which do make the page somewhat more user-friendly. An example is given on my page on Javascript form validation.

Note that it is conceivable that Java, Javascript or Flash might be used for content, and thus fall under level 2. An example could be an animated display to show how a machine or a chemical reaction works. In practice they are used almost exclusively for decoration.

The end result

So what do we achieve if a page is developed according to this model?

If the reader is using a platform which cannot handle one or more of the elements in level 4, the result is still a fully coherent page. The same is true without levels 3 and 4.

If level 2 is missing, the reader may miss some of the essential content of the site, to the extent that it is inherently non-textual. But he can still see what the site is about, so as to be able to decide whether he wishes, for example, to install a plug-in or borrow another computer.

Even if the reader has no access to anything in levels 2, 3 or 4, he can still read the text of the page without difficulty.

• If in a product list some products have an image of a red flag next to them, with the text “New” written on it, then the content is the text “New”. The image of the flag is decoration.
• If a page has a Javascript drop-down menu, the content is the set of HTML links in the menu. The drop-down menu itself is decoration.
• If a piece of Mozart is included on a site which discusses music, and uses it to illustrate a particular musical style, then it is content. If the same piece is included on a site about mountaineering, because the author happens to like Mozart, then it is decoration.
• The photographs included on business-to-business or “branding” sites are typically decorative. However if you include a photograph of the office so that visitors can more easily find it, that would count as content. Even photographs of the company’s products are often decorative – but if they are there to help a potential customer select a product (in a catalogue, for example) then they are of course content.

There may be some marginal cases. For example if a site selling bicycles includes a video of someone riding a bicycle, is that content or decoration? It could be either, though the latter is more likely. But if for example it is a folding bicycle, and you wish to demonstrate how easy it is to fold up, then the video would be content. In this case you should provide a text description of how the bicycle is folded up, and how quickly it can be done, for the benefit of readers without video.

Applying the model

This is all well and good, but how does one use this model?

The key consideration, as you have probably already realised, is to abandon the idea that a site has to look identical in all browsers under all conditions. This is in any case a pointless aim: how many readers go around checking sites in different browsers to see whether they look the same? But it seems nonetheless to be an aim of numerous site owners.

The main techniques are as follows.

1. Use the HTML 4 (or XHTML 1) Strict model, together with CSS, to achieve separation of textual content (Level 1) and presentation (Level 3). Note that this does not guarantee separation on its own. Other forms of HTML presentation, such as sequences of <BR> elements or convoluted nested tables, are equally undesirable.
2. Don’t make a lower level dependent on a higher level: for example don’t deny the content to someone who has Javascript disabled.
3. Produce the initial version of the page without any Decoration (Level 4) at all. Add it once the basic site is working; then retest with decoration formats (Flash etc) disabled to check that the basic page has not been damaged.

   Indeed it may work best to do the page entirely bottom-up, starting with level 1 and working up to 4.

4. Provide, as far as reasonably possible, appropriate fall-back for Level 2 content. The OBJECT element is intended to make this easy, although browser support is not ideal, so some experimentation may be needed. It may turn out to be necessary to provide a link to the alternative content.

In principle Level 2 separates itself out from the other levels automatically. The main confusion factor is people who insert Javascript routines or Java applets, thinking that they are adding content, when it is actually decoration. Javascript, Java and Flash may occasionally be used for content (e.g. games written in Flash), but in practice they are overwhelmingly used for decoration.

Adding Decoration

The main consideration when adding decoration is to do no damage: the page with decoration should be no worse (for any readers) than the page without. You would be astonished how often this rule is broken! I am not referring to questions of style and taste – which are obviously highly debatable – but to cases where adding decoration makes the page unreadable for some visitors.

Examples of techniques to use:

• Where you wish to replace text with a decorative image, put the replaced text in the ALT attribute of the image.
• Where you wish to place text in, say, a Flash or Java animation, ensure the original text remains readable for readers without Flash or Java.
• If you wish to decorate links using Javascript, insert the appropriate script calls in the intrinsic event attributes (onmouseover, onclick etc) leaving the original HREF attribute unchanged.
• Determine whether a particular Javascript feature is supported by using feature detection (also known as object detection) rather than browser sniffing.

Where decoration is simply being added to the site, and does not replace any content, it is not necessary to worry about a hierarchy as with Level 2. There is little point in providing Javascript decoration for readers who can’t see the Flash decoration. If the reader can see the decoration that’s fine; if not then no damage is done.

File Structure

In general, styling and script should be placed in external files, not in the HTML. This is partly to make the separation clearer, and thus maintenance easier, and partly to avoid readers without CSS or Javascript having to download material which they cannot use.

If images are used for both levels 2 and 4, it might be worth splitting the content and decorative files into separate directories. The reason is that decorative images can be updated rather freely, while the modification of content images should be done with more caution. It is conceivable that a site face-lift might involve swapping in a new set of decorative images, while leaving the content images unchanged.

Similarly, should Javascript be used both for content (Level 2) and decoration (Level 4) it would be a good move from a maintenance point of view to separate the Javascript for the two levels into separate files.

Summary

Eric Bohlman, writing in the comp.infosystems.www.authoring.html newsgroup, made a perceptive comment about “dee-zyners” (a mildly pejorative term referring to web authors who place form before function).

I think there’s a fundamental difference in mental model between the “standards” crowd and the “dee-zyner” crowd: the former think that when the viewer browses their work, they, the authors, are guests in the viewer’s space; the latter think that the viewer is a guest in the author’s space.

Well-structured web pages, with levels which relate clearly and systematically to one another, and provide for graceful degradation where necessary, will help a web author to become a valued guest: one who can look forward to a repeat invitation.