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

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) .

Take care,
Rob

Received on Monday, 23 July 2007 18:21:37 UTC