Re: New HTML/XML Task Force Report published

On Mar 22, 2011, at 19:50 , Norman Walsh wrote:
> I've just published the first draft of any actual substance:
> 
>  http://www.w3.org/2010/html-xml/snapshot/report.html

Thanks! Here are some quick notes:

  • if such content was accessible -> were accessible

  • impedement -> impediment

  • "Given that the world at large is unlikely to adopt polyglot markup as the standard way to encode all HTML documents, this solution may have limited applicability." I think that we can be less careful and safely say that it has limited applicability.

  • The XML consuming HTML use case should really point to the Infoset coercion part of HTML: http://dev.w3.org/html5/spec/the-end.html#coercing-an-html-dom-into-an-infoset (probably towards the end where the solution is outlined).

  • "As the HTML5 ecosystem grows, it's easy to imagine a day when HTML5 toolchains are widespread and popular." I think we're there already :) I'd just go with "HTML tool chains are widespread and popular."

  • "These rules will not always produce the same DOM that an XML parser would have produced." In fact, these rules will rarely produce the same DOM. (Should we be saying Infoset? Or don't we care?)

  • I think that the reading XML in an HTML environment use case is a bit weird. At the very least "translating XML to HTML5" would need at least some description of what that entails. I'd tend to think that "parse it with an XML parser, then you have a DOM that can be used in HTML settings" is more realistic. HTML environments do in general tend to have XML parsers around (e.g. DOMParser). Which ones don't?

  • "When the HTML5 parser encounters unfamiliar markup, it assumes that such markup is an erroneous attempt to generate or author valid HTML5." I'm not sure that the parser can be said to being "authoring" content. We might get into tricky lawsuits with that one.

  • "result in a DOM representation that can differ more-or-less arbitrarily from the DOM" I don't think that the differences are more or less arbitrary — but I'd say that it can differ "more or less radically".

  • "by specifying the content type “application/xml”." There's a markup error here (type is <tt> for some reason). Also, I'd add something to the effect of "or any other applicable media type". For instance, SVG Web, which uses this technique, places SVG in script elements with type image/svg+xml.

Do we have a plan for reaching some kind of collective conclusion?

-- 
Robin Berjon - http://berjon.com/

Received on Wednesday, 23 March 2011 12:29:39 UTC