Closed Bug 280692 Opened 20 years ago Closed 3 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: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.