17058 2012-05-15 10:59:35 +0000 Namespace of document.createElement elements. 2012-11-09 15:56:31 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified PC Windows NT RESOLVED WONTFIX P2 normal --- 1 nicholas.stimpson annevk mike www-dom public-webapps-bugzilla oldest_to_newest 67725 0 nicholas.stimpson 2012-05-15 10:59:35 +0000 createElement has the namespace of the element being set to the HTML namespace. Shouldn't that only be the case if the context node is an HTML document? 67726 1 annevk 2012-05-15 11:03:02 +0000 What is the use case for making it conditional? 67729 2 nicholas.stimpson 2012-05-15 11:10:19 +0000 (In reply to comment #1) > What is the use case for making it conditional? Surely it's not backward compatible with DOM3 and earlier for XML documents otherwise. Is that not a concern? 67730 3 nicholas.stimpson 2012-05-15 11:18:34 +0000 (In reply to comment #2) > (In reply to comment #1) > > What is the use case for making it conditional? > > Surely it's not backward compatible with DOM3 and earlier for XML documents > otherwise. Is that not a concern? I mean, I'm not sure what happens for XML documents in browsers. I'm thinking of DOMs built in other contexts. 67731 4 annevk 2012-05-15 11:20:26 +0000 Compatibility with DOM3 is not a goal. DOM4 e.g. completely revamps how Attr are handled (although whether that will work out remains to be seen). 67734 5 nicholas.stimpson 2012-05-15 11:48:20 +0000 (In reply to comment #4) OK. Sounds problematic to me, but so long as you're comfortable with it. Could you make non DOM3 backward-compatibility clearer in the goals section of the document? 67736 6 annevk 2012-05-15 12:11:41 +0000 Would adding "Note: The above implies that compatibility with previous iterations of DOM is not always kept." at the bottom of the goals section help? 67739 7 nicholas.stimpson 2012-05-15 12:45:36 +0000 (In reply to comment #6) Yes, I think it would. But I see changing the way createElement works as pretty fundamental change for almost everyone who manipulates a XML DOM outside of a browser, and that's not really reflected in the goals section (which looks like a set of consolidation, simplification, correction, and extension changes, and therefore not very frightening.) I think it's important that developers know that that if they build a DOM with a DOM4 library, that they may well end up with a fundamentally different DOM to have to process. Particularly in places where DOMs contain a mixture of namespaced elements and elements in no namespace (I've certainly built those in the past), code that tests the element's namespace directly (via namespace-uri() in xpath for example) is liable to need to change. But if attributes are also completely different, then that's going to become pretty obvious quite quickly. 78125 8 annevk 2012-11-09 15:56:31 +0000 Reading Goals again I actually think that "Simplifying them as much as possible." implies it's breaking as it implies removal. Given that we also have bug 19431 now I'm going to mark this one WONTFIX.