W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: Why HTML should be taught as HTML without pretending it is XML

From: Robert Burns <rob@robburns.com>
Date: Mon, 23 Jul 2007 14:04:40 -0500
Message-Id: <E6A11CFA-73B4-4C72-A568-29CBBD318E2C@robburns.com>
Cc: "Jon Barnett" <jonbarnett@gmail.com>, public-html <public-html@w3.org>
To: Simon Pieters <simonp@opera.com>


On Jul 23, 2007, at 1:47 PM, Simon Pieters wrote:

>
> On Mon, 23 Jul 2007 20:21:21 +0200, Robert Burns <rob@robburns.com>  
> wrote:
>
>>> Consistency is not an issue.
>>>
>>> The issue is that, per spec, createElement() creates an element  
>>> *in no namespace*. Not in the HTML namespace. Only Safari follows  
>>> the spec on this point. Firefox uses the HTML namespace if the  
>>> Document node implements the HTMLDocument interface (which is  
>>> when you use application/xhtml+xml). Opera uses the same  
>>> namespace as the root element's namespace.
>>>
>>>    http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-2141741547
>>>
>>
>> It certainly is a matter of consistency. If one sticks with only  
>> non-namespace method calls, it will work with all three of those  
>> approaches
>
> It won't. If you say e.g. document.createElement("input"), it will  
> not be a form control in Safari (which is per spec). It will not  
> implement the HTMLInputElement interface, nor the HTMLElement  
> interface for that matter. It is equivalent to having <input  
> xmlns=""/> in the markup. It does not matter if you only use non- 
> namespeced methods through-out and only one namespace in the  
> document -- createElement() will never create HTML elements in an  
> XML context.

I see what you're saying now. Yes, that would be a problem that would  
have to be dealt with for anyone migrating to XML vended XHTML. This  
is still off-topic, since we're talking about writing XML-like syntax  
and vending it as text/html. The scripting issues in migrating would  
include needing to either invoke NS calls always or at least for  
Safari. This is also the type of thing that WebKit sometimes  
considers changing to fit in; even though they know they got it  
right. I've never understood the reason for null namespaces anyway.  
If someone can enlighten me on that I'd appreciate it. I see that's  
what the DOM recommendation calls for, I just don't understand what  
problem they we're trying to solve (the Opera approach sounds like  
the best way to go; using the root element namespace or perhaps the  
default namespace as the namespace when not specified).

As I said earlier, perhaps there should have been an Appendix E for  
XHTML on migrating to xml vending of appendix C content. However,  
that probably couldn't have been written then since the browsers have  
been moving targets on many of these issues since XHTML 1 was published.

Not to dump on implementors (I'm an implementer too), but I still say  
the creation of XHTML content and vending as text/html is not an  
error of misguided authors. It is authors anxious to move to XML in a  
world where implementations have been slow to step up to the plate.

Take care,
Rob
Received on Monday, 23 July 2007 19:04:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:02 GMT