Web Matters

A four-level model for web pages

  1. Introduction
  2. The perils of lack of structure
  3. Deriving the model
    • The complete model
  4. Distinguishing the levels
  5. Applying the model

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.


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.

Deriving the model

Rather than simply stating what the model is, I will derive it step-by-step, as this should make the concepts clearer.

Separate content from presentation


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.

Content Special plug-ins
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.

Textual content is a bit special though

Non-textual content Special plug-ins
Textual content Text in HTML

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.

4.Decoration Java Flash Script
3.Presentation CSS / non-content images
2.Non-textual content Special plug-ins
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.

Distinguishing the levels

Is the difference between the levels clear? It should not be too difficult to understand the difference between content on the one hand and presentation/decoration on the other hand, but a few examples may make it clearer.

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 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.


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.