Re: xmlns in HTML5

Steven Pemberton wrote:
> On Thu, 16 Jul 2009 07:20:58 +0200, Ian Hickson <ian@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

Received on Thursday, 16 July 2009 15:10:05 UTC