intertwingly

Rob Sayre: this objection wouldn’t be relevant to a document with no “author conformance requirements”, right?

At the present time, the HTML 5 document is a browser behavior specification and a list of author conformance requirements.

The first part is essentially uncontroversial — nobody, including browser vendors like it, but it is what it is, and it ain’t changing. Authors of libraries recognize this too.  Everybody is OK with that.

The second part is the source of seemingly unending controversy.  Are alt attributes required?  What should be considered a conformance error in SVG?  Is RDFa legal? The current draft hasn’t been built based on consensus, and this needs to be resolved prior to Last Call.  Deferring this reminds me of a commercial...

Meanwhile, extensibility and the relative roles of HTML and XHTML2 working groups were hot topics at the AC meeting last month.  Steven Pemberton and I have been having a productive discussion, and we’ve also consulted with a number of AC representatives.  This post is the result of those discussions.  Quick summary:

• I’d like to retain intact the design principles for platform design as worked out by the browser vendorsHTML Working Group in 2007.
• I’d like to relax slightly the design principles for language design, and give considerable latitude to existing designs, as well as grandfather in exceptions.
• I want to explore the idea of dropping the assumption that the current HTML working group has the sole responsibility for, and absolute dominion over, authoring guidelines.

Further background:

At the second AC meeting breakout session, TV Raman made a comment a number of times that we need to partition the idea of extensibility into two parts: extending the platform vs. extending the language.  Those two words didn’t make much sense to me, but his examples did.  Video and 2D graphics are things that need to be implemented by the browser vendors.  And care needs to be taken that such features are defined in a way that they interact consistently with how other parts of the platform interact with other components such as CSS.  Raman refers to these as platform features.

The second type of feature is one that does not need any support by browser vendors other than to simply to parse the unknown elements and attributes into a DOM, and to provide access to the DOM via JavaScript.  RDFa comes to mind as such a feature, as does ubiquity-xforms.  TV Raman refers to these as language features.

I like and endorse TV Raman’s split.  Different burdens of proof and policies need to be applied to each type of feature.

First the obvious: for platform features (i.e., the ones that impact browser implementations), consensus by browser vendors is essential.  I will also note that there are platform features in both of the current HTML5 and XHTML2 published working drafts which do not yet enjoy that level of consensus (trivial example: <q> elements).  My own personal option on how we should deal with this situation is that we should give the HTML5 working draft a severe hair cut (along the lines of Rob’s draft, but perhaps only slightly less brutal), and then add in only the barest necessity of syntax necessary to support platform features required.  I care not what version number of HTML we assign to that document.

For language features, the bar can (and should) be much lower.  Today’s browser have a default rendering and a default mapping to the DOM for unknown markup.  In many cases (e.g., attributes), that means that such markup will not be visible.  An unfortunate consequence of this is an invaluable feedback loop is lost, and therefore data quality will suffer.  We need to agree up front this is entirely the responsibility of library developers to make this stuff visible.  Experience has shown that validators, while necessary and important, are not sufficient. FWIW, a similar observation can be made about lang attributes for non-CJK languages.

Meanwhile, much of the requirements for unfettered language level extensibility come from vendors which produce content via XML pipelines.  Love it or hate it, (and there are plenty in the latter camp even with XML circles) XML namespaces are the way to do such extensibility.  Ben Adida (correctly, in my opinion) observed that the working group that has responsibility for an XML serialization of HTML needs to be aware of and respect such as *a* mechanism for extensibility.  It was also widely observed that those with such pipelines don’t find the distinction between HTML and XHTML to be a useful one as it is only the one that controls the final transfer (and therefore the content-type) that has any control over the serialization.  The obvious implication of this is that markup requirements for language features will bleed through between one serialization and the other.  Direct observation has corroborated this.

My conclusion is that xmlns attributes, and both element and attribute names containing colons, need to be allowed in conformant HTML.  It needs to be noted that such nodes are placed into the DOM today differently by HTML and XML parsers.  This is unfortunate, but given the experience of Opera, it appears to be beyond our ability to correct at this point.  Judging by the people who have coded RDFa and ubiquity-xforms libraries, this is accepted as the cost of doing business on today’s web, and a little JavaScript in a library can smooth over the differences for applications built upon these libraries.  Yes, this will impact people who code validators, but such an impact is much smaller than any impact on content creators.

Effectively this means that Design Principle 3.5 ("DOM Consistency") be relaxed — but for language extensions ONLY.

RDFa and ubiquity-xforms libraries require zero support from browsers today.  I’d like to see an exercise be taken to decide which elements and attributes are to be considered “conformant”, and by that I only mean that such can exist in HTML5 content and not cause a conformance checker to throw up all over the page.  Any additional features required of browsers in support for XForms would have to meet a very high bar indeed and should not be presumed to be included in any revision earlier than HTML6 and quite possibly not even then.

The goal here is not to repeat the exercise where people present use cases and continue to have the HTML working group be a gatekeeper and king maker and sole determinant as to which features are permissible and which are not in the open web.  Specifically, if RDFa is “out”, then I see HTML5 and XHTML2 continuing their separate ways.

On the other hand XForms and RDFa would only be “in” to the extent that they don’t require any browser changes, anything more will have to meet a very high bar.  Additionally, features capriciously removed in HTML 5 such as font and @profile would likely to be restored.

Beyond this the only responsibility we are talking about here for implementers of HTML parsers in general (and browsers in particular) is to place this data into the DOM.  We are not talking about enforcing quotes on attributes, switching to a “real” XML parsers in such instances and building a quilt out of the various DOM fragments produced, or draconian error handling. None of this applies.  The only request is that we explore treating element names with colons in them as foreign content (specifically, the presence or absence of a trailing slash should determine whether the next tag should be treated as a sibling or a child).  As HTML parsers won’t need to deal directly with resolving namespaces, even reparenting nodes isn’t an interoperability issue: libraries that operate on the resulting DOM will consistently evaluate namespaces after the reparenting operation.

So far, I’ve only talked about element and attribute names which contain a colon in them.  Since HTML parsers are unaware of xmlns attributes, it is entirely too dangerous to encourage the use of default namespaces in conformant HTML.

That’s the high level sketch.  As always, the devil’s in the details. We will need to go case by case through the features that are planned for HTML5 and XHTML2 and see how to deal with each one.  Examples:

• SVG and MathML are platform features (i.e., they are visible and interact with CSS).  This means that for these two features, it is important that such markup NOT contain colons in element names.  In such cases xmlns attributes can be used as “talismans”.
• RDFa is a language level feature and defines a small number of attributes without a colon which are to be placed on pre-existing elements which also do not have a colon.  This is something that we will wish to discourage moving forward, but I am entirely prepared to accept that at this point nothing can be done, and these attributes need to be grandfathered in.  The one thing I will insist on, however, is that we treat such as if they are language features and therefore that the responsibility of HTML parsers begins and ends with faithfully transcribing this data into the DOM produced.  Everything else from the interpretation and visualization and feedback loops remain the responsibility of the language designer.  We still have the issue of CURIEs in rels, but I believe that we can address that too.
• ARIA introduces elements and attributes with a common prefix of aria- (as well as a very few attributes which do not follow this convention).  This is a form of lesser-distributed extensibility (specifically, it is non URI based and the prefix is fixed), but the exact same syntax that works in the HTML serialization needs to be supported in the XHTML serialization.

That should be enough examples to illustrate the overall approach.  I’m sure that when we worth trough each feature there will be some tough issues.  But feature by feature, element by element, and attribute by attribute we will need to work through this together.

When we are done, we will have a criterion for determining which features are platform features (and therefore subject to greater scrutiny), and which are language features (and how such are to be expressed in markup in a way that avoids overlap).  Within the scope of platform features, we need to identify the absolute minimum that absolutely needs to go into the next release of HTML (picture the run on the bank scene from It’s a Wonderful Life), and have confidence that there will be a next release of HTML after that one.

One thing I have not talked much about is modularity.  If there are those who wish to pursue a non-normative definition of the XML infoset produced as a result of a parse in terms of an XML Schema, they should be free to do so as long as it remains entirely optional and without requiring any runtime overhead for parsers.  Additionally, such a definition of modularity should in no way endorse the ability for platform vendors to subset and therefore fragment the platform.

I don’t presume that this approach is ideal by any means.  Instead the question is whether or not something along these lines could be something everybody could live with?

This in no way precludes someone or a group producing a separate best practices guidelines for authors, and if they want to suggest that their version of best practices are in conflict with the recommendations of the User Agent Accessibility Guidelines Working Group, the SVG Working Group, the Semantic Web Deployment Working Group, I wish them luck.  An alternate approach would be aim higher and recognize that not everybody will either want to, or be able to, meet that bar.  Make alt attributes a best practice, make quoting attributes a best practice, etc.  If this group focuses on best practices instead of a conformance requirements, it may gain consensus faster.

Such a document could even be generated from the same source file.

But meanwhile, perhaps we can get a candidate recommendation out next year for the browser behavior portions of the document.