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

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[Eric Seidel]

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:
http://bugzilla.opendarwin.org/show_bug.cgi?id=10932
http://bugzilla.opendarwin.org/attachment.cgi?id=10734

easily demonstrates this "bug".

Reproducible: Always

Comment 1

[tor]

No, we won't do this - see bug 353349 and bug 236408 comment 25.

Comment 2

[Boris Zbarsky [:bzbarsky]]

<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...

Comment 3

[Jonathan Watt [:jwatt]]

Yup. That's my problem with this - it just moves and escalates the confusion IMO. Bad idea I think.

Comment 4

[Eric Seidel]

See recent changes in:
http://bugzilla.opendarwin.org/show_bug.cgi?id=10932

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".

Thoughts?

Comment 5

[Anne (:annevk)]

http://bugs.webkit.org/show_bug.cgi?id=10932

Comment 6

[Boris Zbarsky [:bzbarsky]]

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?

Comment 7

[Anne (:annevk)]

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 :-)

Comment 8

[Boris Zbarsky [:bzbarsky]]

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?

Comment 9

[Anne (:annevk)]

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).

Comment 10

[Boris Zbarsky [:bzbarsky]]

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.