This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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?
What is the use case for making it conditional?
(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?
(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.
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).
(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?
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?
(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.
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.