Bug 10932 – SVGDocument::createElement does not create elements in the SVG namespace

• Component: SVG
• Status: RESOLVED WONTFIX

[Matthieu Chaton]

When using the appendchild function, the objects created are effectively in the tree, they are visible when clicking on "inspect element" menu, but they are not shown in the SVG canvas in webkit.

Adobe, Firefox and Opera's implementations are working, but not webkit's one.

Here is the main code of the url submitted below :

<svg width="686.76" height="621" viewBox="0 0 595.275590551 538.582677165" onload='dessin(evt)' onmousemove=" GetTrueCoords(evt); ShowTooltip(evt, true)" onmouseout="ShowTooltip(evt, false)" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="xMidYMid meet" zoomAndPan="magnify">
<script><![CDATA[
var svgdoc,root;
function efface(evt){
	objet=evt.target;
	root.removeChild(objet);
}

function dessin(evt){
	svgdoc=evt.target.ownerDocument;
	root=evt.target;
	for (i=0;i<8;i++){
		node=svgdoc.createElement('rect');
		node.setAttribute('x',10+i*50);node.setAttribute('y','150');
		node.setAttribute('width','30');node.setAttribute('height','150');
		node.setAttribute('style','fill:red');
		node.addEventListener('click',efface,false);
		root.appendChild(node);
	}
}
]]></script>

[Eric Seidel (no email)]

Interesting.  This test fails in Firefox as well, but not Opera.

[Matthieu Chaton]

(In reply to comment #1)
> Interesting.  This test fails in Firefox as well, but not Opera.
> 

In fact I have found what doesn't work : it's the use of createElement, setAttribute And getAttribute instead of createElementNS, setAttributeNS and getAttributeNS.

But I think that not supporting createElement or setAttribute is bad, because they are often used in SVG...

[Eric Seidel (no email)]

Ah.  It's possible that SVGDocument should override the default createElement behavior to use the SVG namespace instead of the HTML namespace.  Not sure.

[Eric Seidel (no email)]

setAttributeNS should not be needed.  Nearly all attributes use a null namespace.

[Eric Seidel (no email)]

Created attachment 10734 [details]
test case demonstrating "bug" -- I'm not sure what's correct behavior here FF agrees, Opera does not

[Eric Seidel (no email)]

Adding Hixie in case he has an opinion on the subject.

[Dave Hyatt]

I'd expect the generic non-namespaced DOM methods for SVG to work like HTML's.

[Eric Seidel (no email)]

http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/DOM3-Core.html#core-ID-2141741547
suggests that createElement should always create an element with namespaceURI null.

But I agree with Dave, as a content author, it would certainly be nice if createElement automatically added the svg namespace for me.

[Eric Seidel (no email)]

Created attachment 10748 [details]
the "fix" and test case

[Eric Seidel (no email)]

r16575. Thanks tim!

[Eric Seidel (no email)]

I've filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=354318
to track Gecko making this change as well.

[Eric Seidel (no email)]

Gecko doesn't want to match Safari/Opera on this issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=354318
https://bugzilla.mozilla.org/show_bug.cgi?id=353349

Honestly I can see both sides.  It's already a little weird that HTML scripts break when moving to xhtml.  it would be weird that SVG scripts broken when moving to inline SVG or XML, or anything other than .svg.  Although content authors already need to be aware that their SVGDocument goes away at that point...  I could go either way.  I think our way is nicer on content authors.  But being different from mozilla on this point is not good long term.

[Dave Hyatt]

We had a nice discussion on IRC, and I agree with Gecko.

I think SVG is more like XHTML than it is like HTML, and so both SVG/XHTML should just make namespace-less elements.

[Eric Seidel (no email)]

Which means we should re-open this bug to roll out the changes.  Thankfully the only thing necessary is to roll out the change, as a working test case was already committed.

Then we should try and convince Opera to follow the fold.

[Ian 'Hixie' Hickson]

createElement(), IMHO, should either use the null namespace, or the XHTML namespace. Either way, it should be consistent across all XML content.

createElement() in text/html content should create elements with the XHTML namespace (according to HTML5).

By making createElement in XML create XHTML, we could have createElement() be consistent across all DOM, regardless of MIME type (XML vs XHTML vs HTML vs SVG). I don't know if that's a win; it does mean that XHTML is somehow a higher class citizen in the DOM than other languages. Making createElement() use the null namespace in XML content makes sense to me, but it probably isn't as useful to authors transitioning from HTML to X(HT)ML.

(SVG authors are not as numerous and in any case should always have been using the createElementNS() methods in the first place, so I don't feel bad for them.)

[Eric Seidel (no email)]

Comment on attachment 10748 [details]
the "fix" and test case

clearing review flag.  All that's left for this bug is rolling out this change.

[Eric Seidel (no email)]

Hixie has proposed an alternative.

We just change createElement to always default to the xhtml namespace.  Then the mental model is, all of the create* function are the "html functions" and create*NS functions are the "new way" to do namespace-aware manipulation.  This is potentially less confusing than create* are "smart" about what the current document is.

I should also note, that mozilla currently special cases xhtml to have createElement return html elements.  That weakens the argument that SVG should not do the same, since "being like xhtml" would mean either returning xhtml namespaced elements (like Hixie is proposing) or returning svg namespaced elements (like this bug meant originally).

[Anne van Kesteren]

What Opera does is the following:

* If it's an XML document you take document.documentElement.namespaceURI
  and use that as a namespace. If that doesn't exist (or is null) you
  use null.
* If it's an HTML document you create a "HTML element" which basically
  behaves like the same element in the XHTML namespace.

This makes pages using document.createElement with <xhtml:html> as root element work as expected and the same goes for <svg:svg> as root element.

Note that the special case for HTML wouldn't be a special case anymore if the parsing section of HTML5 would be implemented.

[Boris Zbarsky]

So out of curiousity, what do other (non-browser) SVG UAs do?

I should note that Opera's behavior has exactly the problem I describe at <https://bugzilla.mozilla.org/show_bug.cgi?id=354318#c2>.

[Nikolas Zimmermann]

The bug itself is fixed, inspecting these elements works fine.

[Darin Adler]

Note that bug 8007 is about the fact that in WebKit createElement doesn't create elements in the HTML namespace either. I'm sure we'll fix both of these bugs at once.

[Alexey Proskuryakov]

Closing as WONTFIX per the discussion above and bug 14506 comment 10 - createElement always uses XHTML namespace now.

[Kevin McCullough]

I made a change that may have affected this (see http://bugs.webkit.org/show_bug.cgi?id=8007) although the test case still passes.