Bug 10932 - SVGDocument::createElement does not create elements in the SVG namespace
Summary: SVGDocument::createElement does not create elements in the SVG namespace
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 420+
Hardware: Macintosh Intel OS X 10.4
: P2 Major
Assignee: Nobody
URL: http://www.dernierage.com/test_a.svg
Depends on:
Reported: 2006-09-19 04:10 PDT by Matthieu Chaton
Modified: 2007-08-08 15:29 PDT (History)
7 users (show)

See Also:

test case demonstrating "bug" -- I'm not sure what's correct behavior here FF agrees, Opera does not (680 bytes, image/svg+xml)
2006-09-24 05:16 PDT, Eric Seidel (no email)
no flags Details
the "fix" and test case (18.00 KB, patch)
2006-09-24 21:45 PDT, Eric Seidel (no email)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matthieu Chaton 2006-09-19 04:10:50 PDT
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">
var svgdoc,root;
function efface(evt){

function dessin(evt){
	for (i=0;i<8;i++){
Comment 1 Eric Seidel (no email) 2006-09-20 16:42:13 PDT
Interesting.  This test fails in Firefox as well, but not Opera.
Comment 2 Matthieu Chaton 2006-09-20 23:12:58 PDT
(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...
Comment 3 Eric Seidel (no email) 2006-09-24 05:02:43 PDT
Ah.  It's possible that SVGDocument should override the default createElement behavior to use the SVG namespace instead of the HTML namespace.  Not sure.
Comment 4 Eric Seidel (no email) 2006-09-24 05:05:34 PDT
setAttributeNS should not be needed.  Nearly all attributes use a null namespace.
Comment 5 Eric Seidel (no email) 2006-09-24 05:16:03 PDT
Created attachment 10734 [details]
test case demonstrating "bug" -- I'm not sure what's correct behavior here FF agrees, Opera does not
Comment 6 Eric Seidel (no email) 2006-09-24 05:53:46 PDT
Adding Hixie in case he has an opinion on the subject.
Comment 7 Dave Hyatt 2006-09-24 14:06:33 PDT
I'd expect the generic non-namespaced DOM methods for SVG to work like HTML's.
Comment 8 Eric Seidel (no email) 2006-09-24 21:17:31 PDT
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.
Comment 9 Eric Seidel (no email) 2006-09-24 21:45:15 PDT
Created attachment 10748 [details]
the "fix" and test case
Comment 10 Eric Seidel (no email) 2006-09-26 05:57:31 PDT
r16575. Thanks tim!
Comment 11 Eric Seidel (no email) 2006-09-26 06:39:38 PDT
I've filed:
to track Gecko making this change as well.
Comment 12 Eric Seidel (no email) 2006-09-26 15:33:52 PDT
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.
Comment 13 Dave Hyatt 2006-09-26 15:43:47 PDT
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.
Comment 14 Eric Seidel (no email) 2006-09-26 15:47:40 PDT
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.
Comment 15 Ian 'Hixie' Hickson 2006-09-26 15:48:37 PDT
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 16 Eric Seidel (no email) 2006-09-26 15:57:15 PDT
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.
Comment 17 Eric Seidel (no email) 2006-09-26 16:19:37 PDT
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).
Comment 18 Anne van Kesteren 2006-10-11 00:58:12 PDT
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.
Comment 19 Boris Zbarsky 2006-10-11 07:31:55 PDT
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>.
Comment 20 Nikolas Zimmermann 2007-06-12 11:24:43 PDT
The bug itself is fixed, inspecting these elements works fine.
Comment 21 Darin Adler 2007-07-09 09:46:44 PDT
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.
Comment 22 Alexey Proskuryakov 2007-07-14 08:56:46 PDT
Closing as WONTFIX per the discussion above and bug 14506 comment 10 - createElement always uses XHTML namespace now.
Comment 23 Kevin McCullough 2007-08-08 15:29:23 PDT
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.