Closed Bug 280692 Opened 20 years ago Closed 4 years ago

createElement breaks DOM spec for HTML and XUL documents

Categories

(Core :: DOM: Core & HTML, defect, P5)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: bzbarsky, Unassigned)

References

Details

Per both DOM2 Core and DOM3 Core, createElement hass: Return Value Element A new Element object with the nodeName attribute set to tagName, and localName, prefix, and namespaceURI set to null. our createElement implementation does not set namespaceURI to null at all. It sets it to the document's mDefaultNameSpaceId. Now I understand the reasons for our behavior, so perhaps we should work on getting errata to the spec. But as things stand, we're broken.
Can things be added to the errata now that the DOM WG is no more?
Blocks: 280693
Alternately, perhaps we should document our behavior in nsIDOMDocument.idl. That's assuming we decide we don't want to follow the spec here.
I really think we should follow the spec here.
jst: this is all you man :) I can't say I have a strong oppinion either way. The DOM spec is a mess when it comes to mixed namespaced and non-namespaced methods. And the current implementation does make it easier to transition to XHTML...
The problem with the current implementation is: how do you know what type the document is? Especially given that I strongly believe that the Document object should be castable to any Document type (HTMLDocument, SVGDocument, etc). (Which is the only thing that really makes sense in a compound-document world where the scripts don't know what the context is.)
--but I agree that it is good for transition. I just don't like the current way of determining the default.
Peter had a possible thought: 1) Keep the behavior for HTML, but hack the DOM getNamespaceURI to return empty/null for nodes created with createElement (note that we always return empty, never null.... but that's a separate story). 2) Fix XUL to not do this any more (and fix our chrome, and break most extensions). Well, this was more my thought; Peter was in favor of treating XUL like HTML, I think. 3) Follow the spec for all else.
I'm more in favour of keeping the current behaviour then. Adding a hack like that would be following the letter of the spec but not the behaviour of it. IMHO what matters is not what namespace namespaceURI returns, but rather what namespace the element acts like. My question is, who would be happier with this approach? I don't entierly see the problem Hixie is talking about in comment 5. If people are worried about what type of element createElement will return they can and should use createElementNS. Same goes for people writing code that could end up in compound documents. The DOM Core spec has always recommended against mixing namespaced and non-namespaced methods. So people doing it anyway are doing risky things.
The problem with XHTML is a significant installed base misusing createElement, at this point, as I understand it... :(
In XUL, I could believe that. Certainly there's not a significant installed base doing _anything_ as far as XHTML goes.
Unfortunately, there is -- various extension authors (not to mention Chatzilla) and people sending the same document as different types depending on the Accept header.... :(
Apart from the extensions, do you mean this list: <http://www.goer.org/Markup/TheXPhiles/> ... I believe the ones using Javascript use this script for createElement: <http://simon.incutio.com/archive/2003/06/15/javascriptWithXML> AFAIK, that does not break anything, does it? And if we need to break it, do it now.
Extensions can be fixed (and in a transition period, maybe we can provide a migration path so that chrome:// code works but gets a warning). The pages that get sent as XHTML will get fixed purely because all those authors are bleeding edge anyway. Now, I agree that it would be very nice if createElement worked in XHTML as well as in HTML, but I don't see a good way of doing that. In the meantime we should fix the implementation to match the spec. The sooner the better or it will get harder and harder. (Note that WHATWG's specs say that createElementNS() with an XHTML namespace should work in an HTML context, which provides the opposite migration path.)
I still don't quite understand the problem here. Is it just the fact that we're not following the spec, or are there other things too. Note that there are other things too where we don't follow the IMHO whacky defined behaviour for mixing namespaced and non-namespaced methods. For example myHTMLInputElement.localName returns 'input' even for htmlelements, and even when using setAttributeNode we don't allow more then one attribute with the same localName+namespace.
Given that we're in violation with the spec in how we implement .localName on elements too, I really don't see why we care about following the spec here in a way that is guaranteed to confuse DOM users. I argued about this in the DOM WG too, but no luck in getting any buy-in, as there were no other member companies that represented browsers at that point. My vote here is to not change anything.
Does "not change anything" mean not changing SVG to behave like HTML and XUL do now? Note that at least some SVG viewers (Batik?) behave for SVG like we do for HTML/XUL. In fact, that's what brought this to my attention in the first place....
Hmm, no, I meant to say to not change how our XUL or HTML works. I'd be fine with making SVG work the same way.
That's fine by me too (see comment 0 and comment 2). Let's just document it, please....
Whatever we do, it has to be very specifically defined so I can updated the Web Apps spec to define this. Other UAs also want to be interoperable here.
Blocks: 296921
My vote is for createElement() to always create nodes in the XHTML namespace.
Component: DOM: HTML → DOM: Core & HTML
QA Contact: ian → general
I suggest marking this WONTFIX. Web DOM Core fixes the spec side: http://simon.html5.org/specs/web-dom-core#dom-document-createelement DevMo already covers documentation.
No longer blocks: 280693
Depends on: 280693
(In reply to comment #21) > I suggest marking this WONTFIX. Web DOM Core fixes the spec side: > http://simon.html5.org/specs/web-dom-core#dom-document-createelement > DevMo already covers documentation. I disagree. Out behaviour is correct in HTML documents, but we should still fix it on the XUL side.
(In reply to comment #22) > (In reply to comment #21) > > I suggest marking this WONTFIX. Web DOM Core fixes the spec side: > > http://simon.html5.org/specs/web-dom-core#dom-document-createelement > > DevMo already covers documentation. > > I disagree. Out behaviour is correct in HTML documents, but we should still fix > it on the XUL side. Just like for HTML content, this would break existing XUL content, make editing more cumbersome, without providing an obvious win.
(In reply to comment #22) > (In reply to comment #21) > > I suggest marking this WONTFIX. Web DOM Core fixes the spec side: > > http://simon.html5.org/specs/web-dom-core#dom-document-createelement > > DevMo already covers documentation. > > I disagree. Out behaviour is correct in HTML documents, but we should still fix > it on the XUL side. Since remote XUL is being disabled and XUL isn't being implemented in other engines, the behavior with XUL documents isn't relevant to Web interop. For XUL, I think it makes more sense to keep the behavior that retains compatibility with existing Firefox extensions. (To be clear, I think createElement in HTML documents should use the http://www.w3.org/1999/xhtml namespace.)
Assignee: general → nobody
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5

No need for correctness in proprietary technology, indeed.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.