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

On Jul 23, 2007, at 10:55 AM, Simon Pieters wrote:

>
> On Mon, 23 Jul 2007 19:39:44 +0200, Robert Burns <rob@robburns.com>  
> wrote:
>
>>> To that, I'll add that document.createElement(), one of the most  
>>> basic
>>> DOM methods, creates an element without a namespace.  If this
>>> quasi-XHTML eventually gets served as XHTML, even
>>> document.createElement would have unintended consequenses.
>>>
>>
>> I forgot to respond to this point. Again, this strikes me as  
>> another non-issue. When working with documents within just the HTML  
>> namespace, it's important to be consistent in those DOM calls. I  
>> don't know of any XHTML implementation that has a problem with  
>> creatElement() as long as you stick with non-NS methods throughout.  
>> Obviously , you cannot work with multiple namespace elements within  
>> one document. However, that should be the biggest caveat of all  
>> when vending as text/html: do not mix elements from different  
>> namespaces.
>
> 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

In WebKit, we recently changed createElement() to always create  
elements in the HTML namespace always. In the future, we'll be making  
all Documents support all Document interfaces including HTMLDocument  
and SVGDocument, regardless of content type or root element. I think  
HTML5 should change to require this even for XML documents (it  
currently requires it only for HTML documents, in the text/html sense).

Regards,
Maciej

Received on Monday, 23 July 2007 21:43:45 UTC