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: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 23 Jul 2007 15:21:55 -0700
Cc: Simon Pieters <simonp@opera.com>, Jon Barnett <jonbarnett@gmail.com>, public-html <public-html@w3.org>
Message-Id: <71701CD8-4E68-4E8E-9594-02056DC757E1@apple.com>
To: Robert Burns <rob@robburns.com>


On Jul 23, 2007, at 11:21 AM, Robert Burns wrote:

>
>
> On Jul 23, 2007, at 12:55 PM, 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
>>
>
> 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 (unless you're saying that a later getElementById() will  
> not work for that element created by createElement())  Again, that's  
> where the consistency comes in: consistently using non-namespace  
> method calls (and of course staying away from compound documents) .

In an XHTML document and in cases where createElement() creates  
elements in the null namespace, using createElement() won't work. The  
default stylesheet won't apply, non-stylesheet rendering rules and  
behaviors for special elements (like <input>, <style>, <link>, <form>)  
won't apply, and HTML-specific scripting interfaces won't be available.

Regards,
Maciej
Received on Monday, 23 July 2007 22:22:10 GMT

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