There's some ongoing debate about whether or how the HTML specification should or shouldn't contain "authoring requirements". I thought I'd write about the general need.
In general, a standard is a (specification of an) interface, across which multiple kinds of agents can communicate. The usual reason for "conformance classes" in protocol specifications is to improve interoperability between agents of the various classes, as an extension of the Robustness principle (or Postel's Law): Be conservative in what you do; be liberal in what you accept from others.
As an engineering principle, robustness predates software by a long shot. There is a standard for railroad tracks, and a separate standard for rail car wheels. The railroad track standard says how wide a track should be, and gives some tolerances which should be kept within. Similarly, a rail car wheel standard would define how far apart the rail car wheels should be, and give restrictions and guidelines on the center of gravity of the car, guidelines on how the flanges of a rail car wheel should be constructed and some tolerances of those. The goal of the standard and the tolerances is to avoid derailment. The rules for the rails and the rules for the rail car wheels go together.
How does this map to the current HTML debate? The current HTML spec contains requirements for HTML interpreting agents (browsers, or the rails); the discussion is around the standards for HTML documents (rail cars) and for the behavior of document producers as well.
The goal of interoperability is to keep the trains on the rails -- to insure that web pages presented are received and interpreted as expected. Following the robustness principle, It is reasonable to have a conservative standard for HTML documents (and authoring tools), and for that standard to be more conservative then would be required if every implementation (rail system) exactly followed all of the standard. Document conformance, recommended document practice, and backward compatible advisory components are all reasonable targets for specification.
Of course, designing a good set of conservative guidelines involves negotiating set of tradeoffs. Is there only one "conservative" guideline? Are there several, depending on the importance of backward compatibility with older browsers? Should the fact that some content was previously conforming have weight? Those are still the open questions.
But conservative guidelines for content and authoring tools are important, and not (as originally noted in the bug report cited above) "ideology" or "loyalty".
Interesting, as I used the Rails and Railway cars analogy at SXSW (in the context that AT vendors are 'waiting' for HTML5 to become a Standard, not just a shifting Spec., so that they can retool their products).
ReplyDelete