Steven Pemberton wrote:
On Thu, 16 Jul 2009 07:20:58 +0200, Ian Hickson <i...@hixie.ch> wrote:
in the HTML5 spec, the only thing that
decides whether a stream of bytes is "XHTML5" or "HTML5" is the MIME
type.
There's no way to send XHTML5 as text/html, because if you send it as
text/html, it is by definition HTML5. (This will probably be made more
explicit once we update the relevant MIME type registrations.)
This is a POV error.
You may have seen the examples of programs that work both as Pascal and
Fortran programs. It's a sort of sport. I have done similar things with
C and sh, so that a file compiles itself; you feed it to sh, and the
shell script part works out things about the C compiler and then feeds
itself to the C compiler [1].
Now, is it a sh script? Yes. Is it a C program? Yes. It is both, and it
only depends on what you feed it to how it gets processed.
I agree with the above.
We tried to allow the same sort of thing with XHTML 1, because we
appreciated that it was going to be some time before browsers processed
XML, but we knew that people with XML production pipelines were itching
to get their XHTML documents out on to the web.
The much-maligned Appendic C guidelines of XHTML1 were only there to
give some hints on how to do this.
If it was much maligned, then perhaps we should consider a different
approach.
So I can send XHTML5 as text/html if I want. It doesn't stop it being
XHTML5, but it does change how it gets processed. Fine.
This is a disagreement on semantics. Calling something as XHTML5 when
it is known that it will not be processed as such seems
counter-productive to me. I, for one, find the definition provided in
HTML 5 more useful than the one provided in Appendix C of XHTML 1.
The text that defines what ends up in the DOM is the parser:
http://www.whatwg.org/specs/web-apps/current-work/#parsing
There are some complications around SVG and MathML (foreign content) in
text/html, but ignoring those, "xmlns" attributes are handled the same as
any unknown attributes in text/html.
I don't think anyone will contradict me if I say this chapter is, how
shall I put it politely, "hard to read", but I have it on good authority
that unknown attributes are left in the DOM. And they better be too,
otherwise there's going to a lot of broken documents on the web soon,
and future versions of HTML will break in HTML5 processors.
The upshot of this is that xmlns attributes will remain in the DOM. This
is good. And it is all we need.
I would actually make that statement stronger. HTML 5 requires that
attributes whose names begin with "xmlns:" be placed in the DOM in a
certain way. This is something that people who are authoring content
can depend on behaving interoperably. If it turns out to be something
that people find useful, and create content with such, and create tools
that consume such, and create specifications which document proper usage
of such, and test suites which enable tools to be compared against the
specifications, and conformance checkers that allow content to be
compared against the specification,.... then it would be
counter-productive of HTML-5 to label such usage as non-conforming.
Steven
[1] http://www.cwi.nl/~steven/enquire.html
- Sam Ruby
