From W3C Wiki
Jump to: navigation, search

Problem Statement

Two W3C Working Groups, the XHTML2 Working Group and the HTML Working Group are both actively defining vocabularies using the same namespace without coordinating their efforts, with the inevitable result that there are two editor's working drafts that normatively define the same XML vocabulary in ways that contain some subtle and a number of not-so-subtle incompatibilities.


The XHTML™ 2.0 W3C Working Draft lists a few major differences from XHTML 1.0, and makes use of a http://www.w3.org/2002/06/xhtml2 namespace. The latest editor's draft presents essentially the same list but reuses the http://www.w3.org/1999/xhtml namespace.

The first and latest W3C HTML 5 working define the use of the http://www.w3.org/1999/xhtml namespace. A list of differences from HTML4 is provided, from which one can readily infer the differences from XHTML1.

Problems Related to Sharing the Same Namespace

These are divided into two types of problems. The first are direct clashes due to the name and defined semantics and processing requiements. The second don't clash directly with the name, but would be problematic to deploy within the same namespace.

Direct Clashes

  • <label>
    • In XHTML2, this is semantically defined as a label for a list. In XHTML1.x, it is defined as a label for a form control. Additionally, although the spec isn't entirely clear, it may also be used as a label for an XForms control. Both of these are semantically different and have significantly different processing requirements from the element as defined in XHTML 1.x.
  • <input>, <select>, <textarea>
    • XHTML2 imports the semantics and processing requirements for these from XForms, which are incompatible with XHTML 1.x
  • <img>
    • In XHTML 1.x, the alt attribute is used to provide alternative text. In XHTML2, the alternate text is provided within the element itself. Such vastly different processing requirements are incompatible with each other and cannot be implemented together in the same implementation. This also breaks compatibility with the text/html serialisation, as is it not possible to include content within the <img> element.
    • Example use case: I'm implementing an editor widget. I would like both XHTML2 and XHTML1 documents to be able to include it. I would like to create valid markup for the editor controls. I want to have some graphical buttons (for inserting headers, indent, outdent, etc, etc). I want to make those buttons accessible via setting their alternate content. I create the editor UI via script (in fact, my whole product is just a JavaScript file that the including page can reference; it can then point me to a particular place in the document and say "put an editor here". It's not clear to me how I can set the alternate content in way that would work for both documents including my script while creating valid markup.
    • XHTML2: Visual user agents must not by default add delimiting quotation marks (as was the case for the q element in earlier versions of XHTML and HTML). It is the responsibility of the document author to add any required quotation marks, either directly in the text, or via a style sheet.
    • HTML5: Quotation punctuation (such as quotation marks) must not appear immediately before, after, or inside q elements; they will be inserted into the rendering by the user agent.
  • 'datetime' attribute serves as a global attribute in XHTML2 for indicating the date and time of an edit and is an attribute on the 'time' element in HTML5 to indicate a machine-readable datetime represented by the 'time' element. While a 'time' element does not exist in XHTML2, the existence of the attribute on a 'time' element might cause ambiguity.

Other Problematic Issues

  • <object src=""> vs. <object data="">
    • Different attributes defined for essentially the same purpose.
  • Renaming <script> to <handler>
    • Different elements defined for essentially the same purpose.

Relevant Messages/Threads

  • Boris Zbarsky: use case/problem of an editing library and what DOM it should produce without a namespace to identify the target vocabulary.
  • Robert Burns: response to Boris Zbarsky use case.