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">
Interesting. This test fails in Firefox as well, but not Opera.
(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...
Ah. It's possible that SVGDocument should override the default createElement behavior to use the SVG namespace instead of the HTML namespace. Not sure.
setAttributeNS should not be needed. Nearly all attributes use a null namespace.
Created attachment 10734 [details]
test case demonstrating "bug" -- I'm not sure what's correct behavior here FF agrees, Opera does not
Adding Hixie in case he has an opinion on the subject.
I'd expect the generic non-namespaced DOM methods for SVG to work like HTML's.
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.
Created attachment 10748 [details]
the "fix" and test case
r16575. Thanks tim!
to track Gecko making this change as well.
Gecko doesn't want to match Safari/Opera on this issue:
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.
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.
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.
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.)
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.
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).
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
* 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.
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>.
The bug itself is fixed, inspecting these elements works fine.
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.
Closing as WONTFIX per the discussion above and bug 14506 comment 10 - createElement always uses XHTML namespace now.
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.