Per Ian Hickson's request, first of my notes on the current HTML 5 draft
Section 1.6.3, where you compare HTML5 with XHTML2 and XForms, you write
"However, XHTML2 and XForms lack features to express the semantics of
many of the non-document types of content often seen on the Web. For
instance, they are not well-suited for marking up forum sites, auction
sites, search engines, online shops, mapping applications, e-mail
applications, word processors, real-time strategy games, and the like.
This specification aims to extend HTML so that it is also suitable in
these contexts."
This sounds more like marketing speak than something one would find in a
specification. If it's important for an individual to know why they
might want to use HTML5 over XHTML2, then the information should be
given in detail, rather than in one vague paragraph.
In addition, I've not found that the HTML5 specification answers the
claims given in the above paragraph. For instance, why would HTML5 be
better for a mapping application than XHTML2? Or an auction site?
In section 1.7, you write
"The "DOM5 HTML", "HTML5", and "XHTML5" representations cannot all
represent the same content. For example, namespaces cannot be
represented using "HTML5", but they are supported in "DOM5 HTML" and
"XHTML5". Similarly, documents that use the noscript feature can be
represented using "HTML5", but cannot be represented with "XHTML5" and
"DOM5 HTML". Comments that contain the string "-->" can be represented
in "DOM5 HTML" but not in "HTML5" and "XHTML5". And so forth."
"And so forth", is not something one wants to read in a specification,
because we expect precision, and "and so forth" is vague, and imprecise.
Since the HTML5 supposedly represents both a HTML and a XHTML
serialization technique, perhaps the document can take a lesson from the
RDF community and provide a separate document, or at least a section
detailing the two different serialization techniques. This would go far,
too, in clearing up the confusion regarding XHTML. Too many people are
making assumptions that "XHTML is dead" because the XHTML serialization
of HTML5 is not spelled out as clearly as it could be.
You actually do mix the differences between the two throughout the
document, but that, to me, seems to 'clutter' up the spec -- making it
difficult to determine what's new in the spec. If the HTML5 document is
a new model for web page markup, then the model aspect of the spec
should be detailed separately from its various serializations, and that
includes any API.
Right now, it's difficult to read the specification because it jumps too
frequently between the abstract and the implementation, sometimes in one
sentence.
More later.
Shelley
