The phrase "graceful degradation" is often used to describe the idea that a Web page that uses special technologies for presentation enhancements, animation, interactivity, etc., should "degrade" to a simpler, yet fully functional page in circumstancies where the technologies are not applicable. This document takes a somewhat different view: instead of considering how to provide "fallbacks" for various advanced constructs, we consider how to create first a robust document that works always, then augment it by providing optional alternatives to the simple constructs. We'll discuss the different techniques that are needed for different enhancements.
Web authoring is more than writing structured texts. There is a wide range of techniques that can be used to enhance pages with other media and possibilities. Given the fact that the Web is a many-faced world where very different devices and environments are used, the key question is how to design pages so that they always work somehow and appear with the enhancements when possible. The key to that is to consider structured text (text with HTML markup indicating its logical structure) as the immutable core of a page, as the solid basis upon which various optional augments can be added. That's my reason for coining the word augmentative in the Web authoring context. In a sense, the point here is that Web pages can be more than text, but they should not be less than text.
Excellent advice on designing Web pages which "degrade gracefully" can be found in the following documents:
My point of view here is somewhat different, though certainly
compatible with "graceful degradation".
I'll first try to explain the idea with
a small but important example: images.
An image is a graphic enhancement to a textual document, and
in good Web authoring, all image elements have adequate
attributes specifying textual replacements for them.
(For specific reasons to this, as well as technical issues on it,
see my Simple guidelines on using
ALT texts in
But the augmentative authoring approach means that
first embedding an image and then wondering (if we remember to do that)
alt attribute to use as a textual surrogate for it,
we first write the text, later build an
element around it, providing an optional graphic alternative.
Simple as that. There's a very practical benefit: the document will
be functional from the very beginning. Generally, the enhancements
take more work and time to implement, like scanning images,
processing them for better quality, etc. (Admittedly sometimes
it takes more work to write a textual replacement for an image
than to put the image onto a page.)
The essential point is that the page can "work" in two modes. For images, this simply means that the page can be viewed so that an image is displayed, or so that some alternative text is presented (displayed or spoken) instead. For a Java applet, it could mean that the page can be used so that the user interacts with an applet that illustrates things dynamically or sees just a static image that illustrates things to the extent that a static image can. For frames, this means that a site can be viewed either using frames or without them, typically using the equivalent of the content of a navigational frame as a main page. And so on. As a special case, one of the modes can be "something extra" like beautiful coloring of a page or checking form data before submitting it whereas the other alternative is simply lack of the extra feature. Quite often style sheets and client-side scripting can be used for such purposes, so that no special "fallback" is provided, since the feature is strictly optional as far as basic functionality is considered. (Note that form data checking must be done server-side in any case, so client-side checks should be just extra comfort.)
This can be characterized by two basic ideas:
The following table tries to summarize the usual
methods for implementing the duality for various enhancements.
Note that several possible enhancements are not mentioned at all,
since they need no special treatment; for example, using style sheets
should cause no problems when style sheets are disabled, if the
HTML markup of the document is adequate.
For details on the HTML elements involved, please refer to
HTML 4.0 Reference by
WDG. For features not in
the HTML 4.0 specification, such as
HTML Tag List by Rob Schlüter
(also available as
a version which uses frames)
or Miko O'Sullivan's excellent
HTML Quick List.
|tag for enhancement
|method of providing a "fallback" alternative
applet element (after eventual
param elements) and/or
|area in a client-side image map
|background sound (automatic)
|none, or provide a normal link to an audio file
|a clickable button for which an associated action is specified via client-side scripting
dynamically, using a scripting language, and provide a non-scripting
noscript if relevant
|embedding various things via output from plug-in applications
noembed, which appears inside the
embed element and contains
an alternative, perhaps a link
|a setting for framed pages
noframes, usually containing the links in the
navigational frames and some short general information; additionally,
a link to a non-framed version containing such data is also
|inline ("floating") frame
|content of the
iframe element, typically
a link to the framed document or a copy of its content
|an embedded image
alt attribute; sometimes a link to the image
or to a document describing its content
|image submit button
attribute (partial fallback)
|client-side image map
alt attribute in
area elements inside; an additional separate textual
menu (or a link to it) is advisable
|inclusion (embedding) of an object
|content of the
noscript element; sometimes (in
conjunction with forms) a server-side script, referred to via
|sometimes a link to a non-table version or a preformatted
plain text version, or
special techniques for non-table browsers
As the table demonstrates, there is great variation in the ways in which the duality can be implemented, both syntactically and as regards to practical flexibility.