For most issues, references are provided to pertinent sections of the HTML 5 draft. Since section numbering has changed since the TAG
began its review, some sections are listed in this form XXXX(YYYY). This is to be read as Section #XXXX in the 25th Aug. working draft of HTML 5; section YYYY in the version that the TAG divyed up for review.
The TAG has not reviewed these. The sections below are divided according to what I suggest might be the significance of these issues
if the TAG decides that any of them have merit.
These are likely to have the most impact on the operation of the Web and the success of HTML 5 overall.
Potential Issue: Lack of clarity on what is an error and what isn't. Need consistent editorial approach.
It's understood that the draft is in part trying to specify what constitutes legal HTML 5 and associated processing, and also
to specify the behavior of user agents parsing and processing input that is not legal HTML.
In some cases, the distinctions seem not to be sufficiently clear. Picking nearly at random some representative examples:
References
- 4.2.4 The link element: "The types of link indicated (the relationships) are given by the value of the rel attribute, which must be present, and must have a value that is a set of space-separated tokens. The allowed values and their meanings are defined in a later section. If the rel attribute is absent, or if the values used are not allowed according to the definitions in this specification, then the element does not define a link." This is one of many cases where the specification calls for processing to continue in a case that is claimed to be "not allowed". I believe the intention is to describe (a) the processing in the correct case, where the values are OK and (b) to define a different world in which the document provided is in error, but processing is to continue. I think the draft would be better if it established clear and consistent terminology, and perhaps even typography, for distinguishing instructions that are intended as fixup for errors from processing of the non-error cases.
- 9.1.2.4: Tags such as HTML start tag or end tag can be omitted (and seemingly the end can be provided without the start). Nothing implies this is an error. Isn't it? Is it legal HTML5 to have an end tag with no corresponding start?
- 9.2: "This specification defines the parsing rules for HTML documents, whether they are syntactically correct or not. " Well, one point of view is that if they're not syntactically correct they are not HTML documents, and indeed could be nowhere close to HTML documents. One possible resolution: define a term, perhaps "purported HTML document" or maybe something less clumsy, to refer to a document that >should< be HTML and is being parsed into an HTML DOM. Then hyperlink that from a revised sentence: "This specification defines the parsing rules for >purported HTML documents<, I.e. those that are being parsed to create an HTML DOM; these rules are applicable even in cases where the document proves not to be syntactically correct HTML. "
- 9.2: Note: "Parse errors are only errors with the syntax of HTML. In addition to checking for parse errors, conformance checkers will also verify that the document obeys all the other conformance requirements described in this specification." Some of the conformance rules are not machine checkable (e.g. that a <table> is semantically a table, <h1> a heading, etc.). This note seems to have a few problems: it appears to define conformance rules for conformance checkers, and it's not clear whether that's a good thing for the HTML specification to do; even if it is, doing so in a Note is problematic, and the current text uses the phrase "will check" rather than "must check". Suggested resolution: eliminate discussion of what conformance checkers will or must do. Separate documents can be written to specify conformance rules for various flavors of conformance checkers, should that prove worthwhile.
- 9.1.24: "A head element's start tag may be omitted if the first thing inside the head element is an element." Could almost be taken to imply that a document consisting only of a <p> is interpretable as having the paragraph inside the <head> (not sure about this).
Potential issue: declarative vs. imperative expositions of validity checks and mappings to DOM
Many of the rules for distinguishing correct syntax, and for mapping input into the DOM, are expressed imperatively.
Some of the concerns I've heard TAG members express about this choice include:
- Declarative expositions might be clearer & easier to follow,
- Declarative expositions are more amenable to automatic implementation and checking, and they support automatic test case generation
- Declarative expositions of syntax can be more useful when building, or checking compatibility of tools (e.g. checking that all the numbers generated by some existing tool conform to a syntax that is legal for an HTML 5 attribute). For example,
checking regular expression extensions, or computing the intersection of regular expressions, can be done automatically.
- Determining equivalence of algorithms is difficult
- Providing algorithms rather than stating invariants makes it difficult or impossible to distinguish between those things that are MUST (all consumers must satisfy these invariants), SHOULD (apply for some categories of consumers but not others) and MAY (suggested algorithms which consumers might use, but are not required to satisfy the needed invariants.) In addition, it complicates or in some cases prevents consideration or documentation of what producers of scripts or markup need to know, which is what invariants they can rely on.
References
Throughout the specification.
Potential issue: algorithm complexity
Many of the step-by-step algorithms are presented in a way that is extremely difficult for a human to parse and check.
Even if the suggestion that the rules be made more declarative is rejected (in some or all cases),
it may be useful to look for other ways of setting out the algorithms.
The case can be made that a more formal programming notation might be just as easy or easier to follow, more precise in its semantics, and
perhaps easier to check or implement automatically in some cases.
References
This is one example of a section that seems particularly long and hard to follow:
- 9.2.2.1: Item 4, beginning with "otherwise the user agent".
Potential issue: document.write() not supported from XML serialization
This may be old news, but I was surprised to see that document.write() is not supported when
parsing the XML serialization. This seems to put the nail in the coffin of XML as a serialization format for
colloquial HTML. I understand that there are a variety of issues in making a sensible definition of how this would work, but my intuition is that it could be done reasonably cleanly (albeit not with most off-the-shelf XML parsers).
References
- 3.5.3 (3.8.2): document.write: "If the method was invoked on an XML document, throw an INVALID_ACCESS_ERR exception and abort these steps."
Potential Issue: Does HTML 5 establish appropriate policies for extensibility?
See discussion below under references.
References
- 3.2.1 (3.3.1) "Authors must not use elements, attributes, and attribute values for purposes other than their appropriate intended semantic purpose. Authors must not use elements, attributes, and attribute values that are not permitted by this specification or other applicable specifications." This is one of the most important sentences in the entire specification, but it's somewhat vague. If "other applicable specifications" means: any specification that anyone claims is applicable to HTML 5 extension, then we can extend the langauge with most any element without breaking conformance; if "applicable specifications" is a smaller (or empty) set, then this may be saying that HTML 5 has limited (or zero) extensibility. Suggested resolution: to make a constructive suggestion here, we have to get some concurrence on decentralized extensibility. My preference is to support decentralized extensibility, in which case this text should be revised to say so. If the decision is not to support decentralized extensibility, then "other applicable specifications" should be turned into a hyperlink that sets down unambiguously the rules for determining whether another specification is "applicable".
- Relating to the above, there is also the provision in 3.2.3(3.3.3) that global attributes "may be specified on all HTML elements (even those not defined in this specification)"; this strongly suggests some sort of extensibility at the element level.
- 3.2.5.1.1 (3.4.1.1): The example shows an XML serialization with embedded namespace-qualified RDF, and states "This isn't possible in the HTML serialization, however." It might be helpful to have a separate section making clear what the extensibility rules are in general, how they affect the DOM (e.g. can you use a script to stick an <rdf:RDF> element into a DOM that was created from an HTML (non-XML) parse?), etc.
- Chapter 4: This is where the elements of HTML are introduced. Each is given a content model (no problem there). It seems that there should be a general statement about extensibility of these models, with reference to the "applicable specifications" extensibility mentioned above.
- 4.2.5.2: "Extensions to the predefined set of metadata names may be registered in the WHATWG Wiki MetaExtensions page. "
- Note that extensibility is also potentially an issue for things like enumerated attribute values, such as for dir (ltr or rtl) -- section 3.2.3.5
There are many instances in which it is stated that "XXXX must happen", but the explanation of XXX is vague or informal, or terms that
probably should be hyperlinks are not linked.
References
There are many, many examples of this, and probably the whole draft should be checked by multiple readers to find them. The following are a few
selected more or less at random to illustrate the concern:
- 3.2.3.7 (3.3.3.7) Style attribute "Documents that use style attributes on any of their elements must still be comprehensible and usable if those attributes were removed." That appears to be a formal "must", but the criterion is informal and not testable. I think this one probably is better as a "should" than a "must".
- 3.2.5.1.7 (3.4.1.7) "When a pointing device is clicked, the user agent must run these steps"... This is a formal must, but there is no clear definition of what it means to click a pointing device. Presumably the intention is to include touch screen taps, etc. but it's not clear that this is enforceable as a conformance clause in general. Suggest replacing with an explanation that "user agents may support means by which users can designated that an element is to be activated: in traditional browsers this is commonly done through the click of a mouse, but other means may be provided instead or in addition. When such a gesture or other means is used to activate an element, the user agent must run these steps..."
- 9.1.2.1 "The next >few< charaacters of a start tag must match the element's name. Wordnet definition (http://wordnetweb.princeton.edu/perl/webwn?s=a%20few) of the word "few" is "(more than one but indefinitely small in number " Seems to specifically rule out matching on one character names, and arguably implies that not all of long names must match. The real issue here is the general level of informality, not patching this one. Note that this vagueness is in the scope of a "must"
- 9.1.2.1 "Attributes may be separated from each other by one or more space characters." Shouldn't that be a "must"? 9.1.2.3 suggests that the answer is "yes"
- 9.1.2.6: "The text in raw text elements and RCDATA elements must not have an escaping text span start that is not followed by an escaping text span end." This is a formal "must" but the term "followed" is not formally defined. Does it mean followed immediately with no intervening chars? Somewhere later? Any restrictions on where later?
A case could be made that the prevalence of problems like this illustrates a more structural weakness relating to the somewhat informal style
of significant parts of the specification.
Potential Issue: Web addresses and URL terminology
The HTML 5 draft uses the term URL, not URI. It's unclear whether the factoring to reference WebAddr and/or IRI-bis will be retained.
References
To be supplied
Potential Issue: Content-type sniffing
HTML 5 calls for user agents to ignore normative Content-type in certain cases.
References
To be supplied
There are many examples where seemingly simple things are spelled out in very careful detail, such as the character codes for the letters H-T-M-L. It then seems surprising when very important concepts are not clearly spelled out or hyperlinked.
References
- 3.5.5(3.8.4): "Remove the child nodes of the node whose innerHTML attribute is being set, firing appropriate mutation events." Why is the term "mutation events" not linked to a formal definition? I suggest that the whole specification be reviewed to identify the many examples, like this, in which formal definitions or hyperlinks should be added (this seems like the sort of job that could well be split across members of a large working group, since it's certainly painful for one or two people to attempt).
Potential issue: "willful violations" of other specifications
HTML 5 acknowledges in several places that it is in "willful violation" of other specifications from the W3C and IETF. Potential concerns include:
- Insofar as the other standards have actual deployed implementations which adhere to them and not to the method or specification in the HTML 5 document, varying from other standards interferes with the interoperability of the web and other systems.
- It may be that this 'willful violation' describes current web practice, but bringing the web into coherence with other applications should be a priority, and efforts made to reduce the causes of interoperability.
- Independent evolution of other standards: even if the HTML specification were in complete agreement with other specifications, the practice of importing other specifications prevents the normal evolution of standards. If it is desirable to specify, for a particular class of agents at a particular point in time, a set of required normative specifications and their versions which 'best practice' for that class of agents, this belongs in a separate applicability statement.
References
A few representative examples:
- 1.5.2: "Compliance with other specifications; This section is non-normative; This specification interacts with and relies on a wide variety of other specifications. In certain circumstances, unfortunately, the desire to be compatible with legacy content has led to this specification violating the requirements of these other specifications. Whenever this has occurred, the transgressions have been noted as "willful violations".
- 2.5.1: "Note: The term "URL" in this specification is used in a manner distinct from the precise technical meaning it is given in RFC 3986. Readers familiar with that RFC will find it easier to read this specification if they pretend the term "URL" as used herein is really called something else altogether. This is a willful violation of RFC 3986. [RFC3986]" (is this required for compatibility w/legacy content)?
- 2.7: "Note: The requirement to treat certain encodings as other encodings according to the table above is a willful violation of the W3C Character Model specification, motivated by a desire for compatibility with legacy content. [CHARMOD]
Potential issue: doctype and explicit version identifiers
The TAG has been exploring the pros and cons of using explicit version identifiers in HTML (and other) documents. Considerations include:
- in-band global version identifiers, if new implementations handle them reasonably, may be useful for (a) authoring applications that want to track
versions used for authoring (b) informative error handling when applications encounter constructs that are apparently 'in error'
References
To be supplied
To be supplied.
To be supplied.