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 17:15:12 -0500
Message-Id: <AA6A0A99-59BC-4B42-9C6E-A390ED3B6FED@robburns.com>
Cc: Simon Pieters <simonp@opera.com>, Jon Barnett <jonbarnett@gmail.com>, public-html <public-html@w3.org>
To: Maciej Stachowiak <mjs@apple.com>

Hi Maciej,

On Jul 23, 2007, at 4:44 PM, Maciej Stachowiak wrote:

> On Jul 23, 2007, at 12:04 PM, Robert Burns wrote:
>>  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).
> Actually, I think always making createElement() create elements in  
> the HTML namespace is the way to go, and better than Opera's  
> approach. The problem with Opera's approach is that cut & pasting  
> snippets of markup that include script into a document in another  
> language could result in surprising changes to the script behavior.  
> Using the HTML namespace removes a problematic HTML/XHTML  
> difference, without introducing the risk of inconsistency between  
> different XML documents.

While, I think generally HTML will take a central role in a lot of  
document-based XML, it also seems overly presumptuous to treat  
everything as HTML. I assume you mean just for the non-namespace DOM  
call (i.e., createElementNS("p", nil) would not create an element in  
the HTML namespace). In any event, I think pasting content is a  
separate issue. That is, if we imagine a pure XML world with many  
namespace, the copy operation should bring with it namespace  
information. Even if you copy form a legacy HTML document and then go  
to paste it into an XML (of some namespace) document, the namespace  
should come with the pasteboard. So even copy and pasting from legacy  
content into XML would indicate a namespace and execute the pasts  
with an explicit namespace. It's in the paste that you could have a  
default namespace if nothing else could be determined.

Also, it strikes me that the assigned namespace could still be  
maintained even if you wanted to implement complete HTML and SVG  
element interfaces. Again, that seems to me to be a separate issue  
than what namespace the elements carry with them.

I still say that Opera has the right approach that abstracts from an  
HTML only world. Whatever namespace the root element occupies is the  
default value for nil (or at least for createElement()). I tend to  
think it would be even better to use the default namespace since the  
author might be saying something with the selection of a default  
namespace (especially when it's selected to be different than the  
host document namespace).

But my real question remains. Does anyone know what rationale the DOM  
folks had in creating elements and attributes and the like without  
any namespace? I see only headaches from that decision. But it  
wouldn't surprise me that I'm just missing something important.

Take care,
Received on Monday, 23 July 2007 22:15:24 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:24 UTC