TAG face-to-face meeting, 23rd-25th September 2008
Ewing Marion Kauffman Foundation, Kansas City, Missouri.

When the world-view was

 HTML will move to XML

the question of how other Web technologies integrated with HTML was usually answered by saying

 XML will bring it all together.

However, that is no longer the case, there is now little or no hope of the HTML5 world converging with the XML family of languages. HTML5 has an XML serialization that is a second-class citizen at best as far as that community is concerned. In the above I said HTML and Web technologies — but that is just my perspective. The HTML5 community would define themselves as encompassing all Web technologies, i.e., if it's not HTML5 and implemented in a browser, it's not the Web. Personally that is a view that I do not subscribe to, but it's important for the TAG to have thought about where we stand globally on this before we get to concrete details, since one's technical stand on any of the issues that arise is deeply affected by the above.

If you take the world-view that the Web is more than a Web Browser, and that Web technology means more than just HTML, then the core issue that underlies each specific technical issue is the following:

 How do you make sure that  XML technologies can co-exist on the Web alongside HTML
without necessarily having  HTML's sloppiness leaking  into all Web languages?

• Modular specs make for easier review, and make addressing issues tractable. At present, each issue that is raised loops back to something else, and worse, the spec is not getting the architectural review it deserves.
• The spec is being cherry-picked by implementations with everyone claiming they're implementing it. But they are all implementing different parts of it.
• Propose a reasonable breakdown based on prior experience.
  • Parsing
  • DOM
  • Serialization (canonical serialization) XML and HTML.
  • Semantics of related groups of elements.
  • Interaction with CSS
  • Interaction with other Web languages –both embedding and being embeded.

Preparation

• Re: brainstorming: test cases, issues, goals, etc. 14 Mar 2007 23:12:55 +0000 regarding dependencies between parts of the spec
• Re: Invitation to the TAG to provide feedback on HTML5 21 May 2008 21:17:20 +0000

As the underlying authoring language for the Web, HTML by definition has to be able to utter phrases in all of the Web's basic technologies, e.g. URLs. Traditionally, building blocks like URLs have been specified outside of HTML, since they need to be used in more than just HTML. This has also left the question of error recovery underspecified. At present, HTML5 is attempting to rectify such under-specified error recovery by trying to write down all of the rules for moving from a sequence of bytes to a URL. This necessarily introduces aspects of the overall HTML5 parsing, and might over time lead to HTML5 error behavior bleeding into the rest of the Web that is more than just browsers.

Preparation

• heads-up about "new" URLs section in HTML5 editor's draft thread 27 to 30 June 2008, ending with endorsement of an objection

 

The Web has been built on (HTTP, URL, HTML). HTML5 impinges on many parts of the HTTP specification and its use. The _ping_ attribute generated much heat and little light before the FF3 launch, and that issue has moved to the back-burner, mostly because FF3 decided to postpone implementing it. But this is not a resolved issue, and HTML5 has many places where it impinges on HTTP. This is of concern wherever those points of intersection are being designed purely from the perspective of the browser. I believe there should be more coordination with the work on updating HTTP that is presently ongoing in the IETF. At present (and this is but a rough sketch) the browser vendors appear to be doing HTML5, everyone else is doing HTTP.

Another core issue that lies at the intersection of HTTP and HTML is the issue of:

Content-Type Sniffing

For reference, that's ISSUE-28 http-mime-override in the HTML WG tracker.

Preparation

• Re: several messages about content sniffing in HTML 29 Feb 2008
• section 2.7 Determining the type of a resource in HTML 5 editor's draft 11 September 2008 (or later)

  Note that a 17 Aug 2007 message from Hickson notes other related sections.

The issue of distributed extensibility and namespaces has been beaten to death. I don't believe anyone in either camp can really be made to change their minds at this point with regard to XML namespaces. The latest proposal from the HTML5 editor to enable extensibility is to stick whatever globally unique identifier one wants in the class attribute. This brings us back to something I observed in 2001

Given CSS and JavaScript, HTML can be reduced to _div_ and _span_.

I later revised this to:

 display:inline allows you reduce this to just one element --- _div_  

Distributed extensibility ends up reducing to a power-struggle between browser vendors who want to dictate what the vocabulary of the Web is — and content creators who do not want to cede this right entirely to the browser. I believe this power struggle to be the root cause of all of the tension that can be observed whenever this issue is brought up.

At this point, I believe we should let the marketplace decide --- it will anyway, with or without the TAG.

But there is a more fundamental design issue that needs to be addressed in this context with respect to the top-level co-existence question we asked in our first session:

Embedding And Embeddability 

1. Given an XML-based language e.g., ATOM, how does one embed HTML content fragments without the HTML5 slopping out into the XML? At present, the only answer is to make the HTML payload a CData section, but in that case, you might as well use something equally opaque like PostScript or PDF.
2. How does one host/embed other languages inside HTML5 e.g., MathML, SVG, or other vocabularies?

This session is for the TAG as a whole to decide how and if we want to move forward with the overall issue of TAG Soup integration.