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.
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.
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.
Rather than simply stating what the model is, I will derive it step-by-step, as this should make the concepts clearer.
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).
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.
|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.
|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.)
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.
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.
|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:
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.
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.
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.
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.
Indeed it may work best to do the page entirely bottom-up, starting with level 1 and working up to 4.
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:
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.
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.