Joe Dolson: Accessible Web Design

The Wikipedia article on Standards in software contains a very good definition of standards, particularly as we might need to view them when talking about web standards:

Standards (software)

Software standards enable software to interoperate. Many things are (somewhat) arbitrary, so the important thing is that everyone agree on what they are. Software standards is one of the Unsolved problems in software engineering

On the whole, the article at Wikipedia is a good example of what isn’t so great about Wikipedia — - poorly written, incomplete: the article is more a collection of notes in preparation for writing an article than it is a real document. Nonetheless, the above definition contains a gem of perception concerning exactly what it is that standards actually do. Standards enable software to interoperate. Standards increase the ability of various programs to cope with what is fed to them.

And, fundamentally, that’s all they do. Standards, by themselves, are not in any way equivalent to “appropriate” or “good.” Web standards enable one program to understand what has been notated in another program. An HTML document may be an incredibly simple and basically inert program, but it is essentially a software program.

But they don’t actually dictate a lot about how that code is actually used, or what elements go into the program.

Let’s try a comparison to cooking. If you’re cooking, you’ll follow a recipe. The recipe dictates units (cups, teaspoons, liters, etc.). The recipe also dictates ingredients, sometimes with substitutions. However, some aspects of a recipe are actually pretty imprecise — - cooking on “medium heat,” “beat until stiff peaks form” or “use one large egg” are all examples of specific directions which do not necessarily convey the information needed to perfect a recipe.

Furthermore, a recipe does not necessarily include every detail of creating the meal — - it may leave out key pieces of information which it assumes you know: stirring the sauce, checking the internal temperature, or removing the pits. These are necessary aspects of preparing the meal right, but which require external knowledge to comprehend.

If you want to bake a cake, you do need to follow the recipe (mostly.) If you substitute baking powder for flour, you will not end up with a particularly appetizing cake — - but you’ll also have problems if you ONLY follow the recipe, and include the eggs with their shells.

Molly Holzschlag mentioned this idea recently, and I’ve certainly written about it before, but it’s a valuable point and worth reviewing.

Besides, I thought of this analogy to cooking the other day while I was making dinner, and just had to get it out of my system…

(Or, more accurately, why the DOCTYPE is no more broken than any other potential switching mechanism.)

In a recent article, “Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8”, Aaron Gustafson states that “the DOCTYPE [is] unsustainable as a switch for standards mode.”

His argument is based on the problem that many developers and authoring tools now make use of correct DOCTYPEs despite the fact that they are not in fact using standards-based, valid code. Therefore, you can not actually assume that a valid DOCTYPE actually indicates the presence of the type of HTML code it claims.

Yes. This is true.

However, he then continues to state that a reasonable solution for this issue is to create yet another standards-based rendering switch. How is this logical?

Let’s review: the reason the current DOCTYPE switching mechanism is broken is because developers and authoring tools don’t use it correctly. The solution? Create a new switch which…can also be misused very easily.

…we’re really only left with one option for guaranteeing a site we build today will look as good and work as well in five years as it does today: define a list of browser versions that the site was built and tested on, and then require that browser makers implement a way to use legacy rendering and scripting engines to display the site as it was intended—well into the future. Aaron Gustafson

That’s a great idea, except for the minor flaw that there’s absolutely nothing stopping developers from misusing it in exactly the same way they have misused the DOCTYPE. Authoring tools may add an auto-generated list of default browsers, developers may cut and paste from other sites without understanding what they are using (much like some currently do) or (undoubtedly) new browsers will be developed which either ignore these switches or mis-interpret them.

I think that there’s a certain amount of sense in stating the exact state of browsers when your site was launched. I can see distinct value to being able to state that your site was developed and tested on Firefox 3, Internet Explorer 8 and Opera 9.732. I can certainly understand that this can help future browsers understand how to interpret your older code: when Firefox 14 is released, it will (hypothetically) simply incorporate the rendering rules from version 3, apply them, and there you are: a perfectly rendering web site. Complete with all the limitations it had when it was built, and incapable of taking advantage of any superior changes in rendering that a well-authored and standards compliant site perhaps could have benefited from.

I do feel that it is a serious mistake to consider this to be any kind of long-term solution, however. In reality, it’s just another requirement which can be mis-used exactly like any other.

The solution (which is not, of course, a popular one) is actually attentive developers who are prepared to make changes to their sites when new browsers are released. Developing to standards is a great way to ensure minimum requirements for redevelopment: why should we add yet another feature to pander to developers who refuse to observe basic minimum standards of coding?