Bug 17058 - Namespace of document.createElement elements.
Namespace of document.createElement elements.
Status: RESOLVED WONTFIX
Product: WebAppsWG
Classification: Unclassified
Component: DOM
unspecified
PC Windows NT
: P2 normal
: ---
Assigned To: Anne
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-15 10:59 UTC by Nicholas Stimpson
Modified: 2012-11-09 15:56 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicholas Stimpson 2012-05-15 10:59:35 UTC
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?
Comment 1 Anne 2012-05-15 11:03:02 UTC
What is the use case for making it conditional?
Comment 2 Nicholas Stimpson 2012-05-15 11:10:19 UTC
(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?
Comment 3 Nicholas Stimpson 2012-05-15 11:18:34 UTC
(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.
Comment 4 Anne 2012-05-15 11:20:26 UTC
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).
Comment 5 Nicholas Stimpson 2012-05-15 11:48:20 UTC
(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?
Comment 6 Anne 2012-05-15 12:11:41 UTC
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?
Comment 7 Nicholas Stimpson 2012-05-15 12:45:36 UTC
(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.
Comment 8 Anne 2012-11-09 15:56:31 UTC
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.