Closed Bug 354318 Opened 13 years ago Closed 13 years ago

SVGDocument::createElement(tagName) should create elements with an SVG namespace


(Core :: SVG, defect)

Not set





(Reporter: mozilla, Unassigned)




User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Safari/419.3
Build Identifier: 

SVGDocument::createElement(tagName) should create elements with an SVG namespace

The W3C DOM 3 Core spec says that Document::createElement('foo') should create an element with the localName = 'foo' and a namespaceURI = null.

HTMLDocument::createElement('foo') violates this, by creating an element with namespaceURI set to the xhtml namespace.

Safari and Opera have conciously chosen to violate the W3C DOM 3 Core spec a similar way for SVGDocument::createElement('foo').  This bug is to ask Gecko to do the same.

The reason we have chosen to violate the W3C spec in this manner, and match HTMLDocument::createElement behavior is for easy of understanding on the part of content authors.

The test case attached to the WebKit bug:

easily demonstrates this "bug".

Reproducible: Always
No, we won't do this - see bug 353349 and bug 236408 comment 25.
Closed: 13 years ago
Resolution: --- → WONTFIX
<sigh>.  If the world does it, we may be forced to by website compat.  :(  But note that this will mean scripts can't be transplanted from SVG documents to inline SVG, which I think severely decreases lack of understanding...
Yup. That's my problem with this - it just moves and escalates the confusion IMO. Bad idea I think.
See recent changes in:

Hixie has proposed an alternative:
createElement returns HTML elements everywhere.
That would shift the web developer mental model from "createElement just automatically uses the correct namespace" (like they expect from html and mozilla's xhtml support), to "createElement is the old-style html-only function, always returns html elements".

Yes, we know.  See comment 0 and comment 4.

That said, Opera's behavior there is a flat-out violation of the DOM spec, no?
Euhm, I just gave a link that works (I have no redirect from opendarwin at least).

And yes, it's a violation, but I don't really see how it's different from doing magic when the media type is application/xhtml+xml :-)
It's different because the XHTML behavior is essentially there because some pages are served as tag-soup to some browsers and XHTML to others, and use createElement because it works in tag-soup.

No one's serving SVG as tag-soup, right?
The problem is that content out there uses it (the Adobe plugin supports it, iirc). And people are complaining if we break that (likely the same reason you guys have this bug).
We have this bug because the webkit folks filed it.

And yes, the Adobe plugin violates all sorts of DOM and CSS specs in fun ways.  I really don't consider the Adobe plugin a useful SVG UA to measure against at this point.  Do see my comment in the webkit bug asking about SVG UAs in general, though.
Duplicate of this bug: 318947
Duplicate of this bug: 398513
You need to log in before you can comment on or make changes to this bug.