- From: Robert Burns <rob@robburns.com>
- Date: Mon, 23 Jul 2007 17:15:12 -0500
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Simon Pieters <simonp@opera.com>, Jon Barnett <jonbarnett@gmail.com>, public-html <public-html@w3.org>
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, Rob
Received on Monday, 23 July 2007 22:15:24 UTC