Last Comment Bug 280692 - createElement breaks DOM spec for HTML and XUL documents
: createElement breaks DOM spec for HTML and XUL documents
Status: NEW
:
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: x86 Linux
: -- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 280693
Blocks: 296921
  Show dependency treegraph
 
Reported: 2005-02-01 11:13 PST by Boris Zbarsky [:bz] (Out June 25-July 6)
Modified: 2014-04-18 06:25 PDT (History)
23 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-01 11:13:22 PST
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.
Comment 1 Jonas Sicking (:sicking) PTO Until July 5th 2005-02-01 11:16:54 PST
Can things be added to the errata now that the DOM WG is no more?
Comment 2 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-01 11:22:54 PST
Alternately, perhaps we should document our behavior in nsIDOMDocument.idl. 
That's assuming we decide we don't want to follow the spec here.
Comment 3 Hixie (not reading bugmail) 2005-02-02 04:20:32 PST
I really think we should follow the spec here.
Comment 4 Jonas Sicking (:sicking) PTO Until July 5th 2005-02-02 05:26:26 PST
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...
Comment 5 Hixie (not reading bugmail) 2005-02-02 06:42:07 PST
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.)
Comment 6 Hixie (not reading bugmail) 2005-02-02 06:46:15 PST
--but I agree that it is good for transition. I just don't like the current way
of determining the default.
Comment 7 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-02 08:23:26 PST
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.
Comment 8 Jonas Sicking (:sicking) PTO Until July 5th 2005-02-02 08:45:27 PST
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.
Comment 9 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-02 08:52:49 PST
The problem with XHTML is a significant installed base misusing createElement,
at this point, as I understand it... :(
Comment 10 Hixie (not reading bugmail) 2005-02-02 15:37:15 PST
In XUL, I could believe that. Certainly there's not a significant installed base
doing _anything_ as far as XHTML goes.
Comment 11 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-02 20:27:13 PST
Unfortunately, there is -- various extension authors (not to mention Chatzilla)
and people sending the same document as different types depending on the Accept
header.... :(
Comment 12 Anne (:annevk) 2005-02-02 23:56:14 PST
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.
Comment 13 Hixie (not reading bugmail) 2005-02-03 03:47:16 PST
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.)
Comment 14 Jonas Sicking (:sicking) PTO Until July 5th 2005-02-03 06:03:08 PST
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.
Comment 15 Johnny Stenback (:jst, jst@mozilla.com) 2005-02-03 17:20:21 PST
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. 
Comment 16 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-03 19:48:08 PST
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....
Comment 17 Johnny Stenback (:jst, jst@mozilla.com) 2005-02-03 20:32:30 PST
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.
Comment 18 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-02-03 20:47:53 PST
That's fine by me too (see comment 0 and comment 2).  Let's just document it,
please....
Comment 19 Hixie (not reading bugmail) 2005-02-04 04:36:59 PST
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.
Comment 20 Hixie (not reading bugmail) 2007-05-24 15:46:55 PDT
My vote is for createElement() to always create nodes in the XHTML namespace.
Comment 21 Henri Sivonen (:hsivonen) 2009-08-20 01:32:43 PDT
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.
Comment 22 :Ms2ger 2010-08-07 04:22:44 PDT
(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.
Comment 23 Dão Gottwald [:dao] 2010-08-07 05:11:01 PDT
(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.
Comment 24 Henri Sivonen (:hsivonen) 2010-08-23 06:05:48 PDT
(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.)

Note You need to log in before you can comment on or make changes to this bug.