262166 - Enhancement patch for supporting printNode, parseXML, getURL and postURL in SVG documents.

Status: RESOLVED WONTFIX

(Core :: SVG, enhancement)

Description

[Jim Ley]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040906

Simple script wrappers around native DOM methods to provide the common (and 
proposed SVG 1.2) methods getURL, postURL and printNode and parseXML - I 
believe they're reasonably complete duplications of the ASV and Batik 
implementations, although there's no test suite - tested them out on some good 
sample code though (the lack of text/ecmascript support hurts most testing of 
existing content)

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Jim Ley]

Attachment: Patch to provide functionality described in the bug.

Comment 2

[Jim Ley]

Attachment: un-tabbed version of the patch to svgBindings.xml

Comment 3

[Jim Ley]

Attachment: patch to the svg.css file

Comment 4

[Hixie (not reading bugmail)]

SVG 1.2 is not yet in candidate recommendation.

Comment 5

[Jim Ley]

Could you explain the relevance to SVG 1.2 not being a candidate recomendation 
is to rejecting these patches?   Mozilla is full of implementations of non-
standard proprietary extensions that are implemented because of the huge amount 
of existing content that relies on them.  This is no different.  Could you 
clarify why this is rejected?  I've re-opened the issue (even in the situation 
that it's decide to reject until SVG 1.2 is in CR it's ridiculous to reject a 
patch because it's a few months too early.)

Comment 6

[Hixie (not reading bugmail)]

The whole point of working drafts is that they should not be implemented in 
release products. Doing so invites problems, for example when the spec changes 
causing any shipped implementations to be incompatible with compliant UAs.

Comment 7

[Alex Fritze]

Comment on attachment 160552 [details] [diff] [review]
un-tabbed version of the patch to svgBindings.xml

>*** svgBindings.xml~	Fri Jun 25 09:15:28 2004
>--- svgBindings.xml	Wed Sep 29 20:45:29 2004
[...]
>+   <binding id="script" extends="svg:generic">
>+    <implementation>
>+     <constructor>

Can you please add a comment here about the function being a 1.2 SVGWindow
function + reference to specs.
Also, you probably want to wrap this in a CDATA-section

>+  Window.prototype.getURL=function(url,fn) { 
>+   var xmlhttp=new HTTP();
>+    xmlhttp.open("GET",url,true);
>+    xmlhttp.onreadystatechange=function() {
>+     if (xmlhttp.readyState==4) {
>+       try {
>+         fn({status:xmlhttp.status,content:xmlhttp.responseText,contentType:xmlhttp.getResponseHeader("Content-Type")})

Shouldn't this be 'success' instead of 'status' ?

>+       } catch (e) {
>+         fn.operationComplete({status:xmlhttp.status,content:xmlhttp.responseText,contentType:xmlhttp.getResponseHeader("Content-Type")})

What's this?

>+       }
>+     }
>+    }
>+    xmlhttp.send(null)
>+  }

Please add a comment here as well.

>+   Window.prototype.postURL=function(url,txt,fn,type,enc) {
>+   var xmlhttp=new HTTP();
>+    xmlhttp.open("POST",url,true);
>+    if (enc) xmlhttp.setRequestHeader("Content-Encoding",enc)

Missing semicolon.

>+    if (type) xmlhttp.setRequestHeader("Content-Type",type)

Missing semicolon.

>+    xmlhttp.onreadystatechange=function() {
>+     if (xmlhttp.readyState==4) {
>+      try {  
>+       fn({status:xmlhttp.status,content:xmlhttp.responseText,
>+        contentType:xmlhttp.getResponseHeader("Content-Type")})

Missing semicolon.
Also, should be 'success' instead of 'status'?

>+      } catch (e) {
>+       fn.operationComplete({status:xmlhttp.status,content:xmlhttp.responseText,contentType:xmlhttp.getResponseHeader("Content-Type")})

???

>+      }
>+     }
>+    }
>+    xmlhttp.send(txt)

Missing semicolon

>+  }

Missing semicolon

>+ 

Again, please add a comment

>+   Window.prototype.parseXML = function (s,doc) {
>+     if (doc==null) {
>+       doc=(new DOMParser()).parseFromString(s, "text/xml");
>+       return doc;
>+     } else {
>+       doc2=(new DOMParser()).parseFromString(s, "text/xml");

Missing 'var'.

>+       doc.importNode(doc2, true)

Missing semicolon.

>+       return doc2;
>+     }

Missing semicolon.

And please add another comment
>+   Window.prototype.printNode= function (el) {
>+    return (new XMLSerializer()).serializeToString(el);
>+   };
>+     </constructor>
>+   </implementation>
>+ </binding>  
>+ 
>+ 
>  </bindings>

Comment 8

[Alex Fritze]

(In reply to comment #6)
> The whole point of working drafts is that they should not be implemented in 
> release products. Doing so invites problems, for example when the spec changes 
> causing any shipped implementations to be incompatible with compliant UAs.

Hixie: Please don't just close bugs like that. We decided the other day on IRC
that we want this in. Should the specs really change I don't see that as being a
problem - people using these features in moz svg have to understand that they
are not standardized yet.

Comment 9

[Alex Fritze]

Comment on attachment 160554 [details] [diff] [review]
patch to the svg.css file

>*** svg.css~	Sun Apr 18 09:15:34 2004
[...]
>+ script {
>+   -moz-binding:url('chrome://svg/content/svgBindings.xml#script'); 
>+ }

Can you please add a comment explaining that you'd actually like to bind to
svg:svg, and that the binding is purely there for the side-effect of defining
some SVG 2.2 Window members.

Comment 10

[David Baron :dbaron:]

(In reply to comment #8)
> problem - people using these features in moz svg have to understand that they
> are not standardized yet.

That's not how the Web works.  If you're serious about wanting SVG to be on by
default in Mozilla, then you need to be willing to follow the same rules about
standards and stability that the other specifications we implement do (for good
reasons).

Comment 11

[Jim Ley]

David, the XML HTTP Request object is being standardised by the WHAT WG, the 
Web Applications specification is not at a call for implementation phase, 
therefore by the very rules your stating it should not be in Mozilla, as it is, 
it's clearly not as clear cut as you describe.

Could you clarify the rules please, what de-facto standards being "ratified" by 
standards organisations are included in Mozilla, and which are rejected?

Comment 12

[Jim Ley]

Ian,  

The SVG 1.2 draft contains entries which are simply reflections of current de-
facto standards, just like the WHAT-WG's standardisation of the XML HTTP 
Request object - something that does exist in Mozilla.  What happens if the 
WHAT-WG change that interface before it goes to the call to implementation 
phase?

This functionality is very important to legacy SVG content.  

Jim.

Comment 13

[Alex Fritze]

(In reply to comment #10)
> (In reply to comment #8)
> > problem - people using these features in moz svg have to understand that they
> > are not standardized yet.
> 
> That's not how the Web works. 

Yes it is.

 If you're serious about wanting SVG to be on by
> default in Mozilla, then you need to be willing to follow the same rules about
> standards and stability that the other specifications we implement do (for good
> reasons).

Would these be the same rules that gave us -moz-border-radius, -moz-user-focus,
etc. :-)

Comment 14

[Jim Ley]

Attachment: svg.css patch

changes as per review.

Comment 15

[Jim Ley]

Attachment: svgBindings.xml patch

Changes as per review

Comment 16

[Brendan Eich [:brendan]]

> What happens if the WHAT-WG change [XMLHttpRequest] before it goes to the call
> to implementation phase?

A de-facto standard is what it is.  If the WHAT-WG is insane enough to try to
change XMLHttpRequest in the face of IE market share, GMail, etc. etc., they
will regret it.

> Would these be the same rules that gave us -moz-border-radius,
> -moz-user-focus, etc. :-)

No, because those non-standard extensions hide in -moz-land.

What dbaron meant by "the web" was exactly the w3c rule for draft
recommendations not yet at CR.  That rule is followed for CSS outside of the
-moz- namespace.

Is there any benefit to making these not-yet-CR features "experimental" by some
similar naming scheme?

/be

Comment 17

[Hixie (not reading bugmail)]

> Would these be the same rules that gave us -moz-border-radius, -moz-user-
> focus, etc. :-)

Yes. mozPrintNode, mozParseXML, etc, would be more acceptable. W3C rules dictate 
that drafts must not be implemented in release products for the very reasons I 
gave in comment 6. If you're going to violate these rules, the least you can do 
is prefix the identifiers so that they won't clash when the spec changes.

Comment 18

[Jim Ley]

I don't understand the comment Brendan, you're saying de-facto standards are 
pefectly appropriate for Mozilla to include, yet this enhancement was marked 
invalid - yet it's an implementation of a de-facto standard just as the 
xmlhttprequest is - considerably more important one to SVG than xmlhttp is to 
HTML (in terms of %age of existing legacy content that requires it. And GMail 
etc. did not use xmlhttprequest until mozilla implemented it.)

The W3c are in as much of a position as the WHAT-WG at being unable to change 
the definitions due to the amount of legacy content.

Is there a document anywhere on mozilla that explains the situation of what de-
facto standards it supports, and which are unavailable for consideration?

Comment 19

[Jim Ley]

Ian, could you provide a link to those W3 rules?

Cheers,

Comment 20

[Hixie (not reading bugmail)]

   http://www.w3.org/Guide/pubrules
   http://www.w3.org/Consortium/Process/

I'm not interested in entering a pedantic argument if you can't find text that 
explicitly recommends restraint in implementations. The problems with people 
implementing specs in shipping products before they reach a mature level are 
well known; claiming it is otherwise is foolish and merely demonstrates a lack 
of experience with software development in multiple-vendor markets.

Could you provide us with links to existing content showing how wide-spread 
these methods are, and provide documentation from vendors that have implemented 
these methods, showing how they are compatible with each other and how the W3C 
is therefore unlikely to deviate from their definitions?

Given the number of existing ways for getting remote content loaded into 
documents, I am very reluctant to see _yet another_ method be added to the list 
of possibilities authors have to deal with, especially given the redundancy of 
these calls with both DOM3 Load and Save and the very widely implemented 
XMLHttpRequest object.

Issues with the patch at hand:
 * It adds functions to the Window prototype, not the SVGWindow prototype.
 * It adds functions to the window object, which, as experience has shown,
   will cause content to break due to name clashes.
 * It adds functions to the window object when <svg:svg> documents are inserted
   into the document, which means scripts that create such elements do not 
   immediately find the relevant functions.
 * No security precautions are made to prevent cross-site downloads, which is
   especially relevant here given that the security level of chrome bindings
   may change.
 * The functions added to the window object are not removed when SVG is removed
   from the document.
 * Every time the SVG element binding changes, the functions are re-added to the
   window object, overwritting author changes.

Comment 21

[Jim Ley]

I still can't find it in those URL's, I acknowledge the problem with premature 
implementation, but like so much of the de-facto standards Mozilla supports, 
it's a judgement call, which is why I'm trying to convince the judgement call 
is reasonable to make.

Mozilla SVG is not released yet, so the release argument is not reasonable (and 
the number of SVG test cases the SVG Mozilla implementations is a much larger 
argument that it should not be released, premature release of partial 
implementations also harms interopability)  with this in mind including these 
methods which significantly aid the testing of SVG content from vendors for 
when Mozilla SVG is to a release standard.

http://www.adobe.com/svg/indepth/pdfs/SVG_current_support.pdf
http://xml.apache.org/batik/javadoc/org/apache/batik/bridge/ScriptingEnvironment
.Window.html
http://svg.kde.org/ecma_overview.html

There are also implementations in other SVG UA's but I do not know of any 
public documentation, and the implementations are mostly private at this time.  
As you can see viewer support is widespread. On SVG content themselves, like 
the xmlhttprequest object, the majority of content (like the majority of SVG 
content itself) is off the web, in controlled intranet environments.  Any 
perusal of the svg-developers mailing list will show what percentage are using 
these features. 

Here is a list of SVG presentations at the recent SVG Open conference which I 
know were presenting SVG content which relied on these methods:

http://www.svgopen.org/2004/papers/SVG_Open_Abstract
http://www.svgopen.org/2004/paperAbstracts/WebEnabledPublicHealthGIS.html
http://www.svgopen.org/2004/paperAbstracts/svg04swa.html
http://www.svgopen.org/2004/paperAbstracts/SPARK.html
http://www.svgopen.org/2004/paperAbstracts/svgscadav3.xml
http://www.svgopen.org/2004/paperAbstracts/guDynamicalVI3.html
http://www.svgopen.org/2004/paperAbstracts/coolSVGEffects.html
http://www.svgopen.org/2004/paperAbstracts/AeronauticalCharts.html
http://www.svgopen.org/2004/paperAbstracts/ClinicalStudyToSVG.html

Actually, I'll give up there, I was about 1/3 way through the presentations, 
most of the others also use the methods.  They're fundamental to all scripted 
SVG solutions currently - Yes Mozilla provides alternative interfaces by virtue 
of its mixed SVG/HTML environment - but for interopability with other 
image/svg+xml clients these methods are essential.

I'll comment on the technical patch issues in a seperate message.

Comment 22

[Jim Ley]

 * It adds functions to the window object, which, as experience has shown,
   will cause content to break due to name clashes.

Since when SVG 1.2 is in CR this will happen anyway, I do not see this as a 
problem that can be solved, or that's relevant.

 * It adds functions to the window object when <svg:svg> documents are inserted
   into the document, which means scripts that create such elements do not 
   immediately find the relevant functions.

Scripts cannot have an SVGWindow object until svg content is in the document, 
so this is not relevant (or do you have other SVGWindow object constructors?)  
The patch clearly isn't perfect in its implementation (it inserts on svg:script 
for example due to other mozilla bugs) but the problems with it are edge cases, 
and it's a good place to start.

 * No security precautions are made to prevent cross-site downloads, which is
   especially relevant here given that the security level of chrome bindings
   may change.

I understood the script would be executed in the context of the calling 
function, I am surprised to find out how it would be otherwise (AIUI the 
resulting getURL calls are not run in the context of the chrome:// security 
context, if I'm wrong, could you please direct me to some documentation on how 
chrome functions like this are handled?)

 * The functions added to the window object are not removed when SVG is removed
   from the document.

So a destructor element which did this would be appropriate you feel?  That's 
certainly easy enough to add.

 * Every time the SVG element binding changes, the functions are re-added to the
   window object, overwritting author changes.

As these methods are not overwritable in other SVG User agents, I don't feel 
this is much concern, however I can certainly add in protection for it without 
difficulty.    

Once the non-technical parts of this bug are resolved I'll make the various 
changes outlined above.

Comment 23

[Hixie (not reading bugmail)]

IMHO, given the problems listed above, if this was to be implemented it would 
have to be done in the window object supported by all content. I am very 
unconfortable with the idea that the fields available on the Window interface 
should change based on whether the document happens to contain nodes from a 
particular namespace or not, and see nothing to support this behaviour either in 
other UAs or in any specs.

But given the limited use of these functions so far (no examples in the wild) 
and the number of alternative functions that already do these tasks (both in de-
jure and de-facto standards), I am not still convinced this is needed at all. At 
some point, we have to draw the line and say "enough with reinventing the wheel,
just use what already exists".

Comment 24

[Jim Ley]

"No examples in the wild"?   I'm sorry, did you not bother to read the long 
list of URLS I provided, listing the large amount of content that are using 
these features?  I could list more, but I really don't see it as worthwhile, 
please look at any SVG content on the web, tha vast majority will use these.

Other UA's are not mixed namespace, so the relavance to other UA's not changing 
the interface dependant on elements in different namespace is not relevant.

If the SVG 1.2 WD continues to CR without change in this area, Mozilla SVG will 
need to support this in any case if it wishes to be conformant, so the "re-
inventing the wheel" argument is not a valid one for this forum.  (And as you 
claim to be a member of the SVG WG, you can make such representations in the 
appropriate place.)

The decision whether to include de-facto standards in Mozilla has always been 
on the amount of content that already uses it.  These methods are required by 
the vast majority of scripted SVG content available today, a Mozilla SVG 
without will be useless for almost all legacy content.  

All of your arguments are on the weakness of the implementation - the fact it's 
only there if svg:script is contained in the document, it being on the Window 
interface etc. - other than the "there's other ways to do it argument".  Am I 
to assume that an implementation without this problems would be perfectly 
acceptable to Mozilla QA?

Comment 25

[Benjamin Smedberg]

> If the SVG 1.2 WD continues to CR without change in this area, Mozilla SVG will 
> need to support this in any case if it wishes to be conformant, so the "re-

At the present time I don't see much point in gecko implementing SVG1.2. It is a
massive and bloated spec which tries to be "all things to all men". The
duplication with existing (much more widely used and tested) de facto standards
is one of the primary reasons not to implement this portion of the spec.

Comment 26

[Hixie (not reading bugmail)]

> "No examples in the wild"?   I'm sorry, did you not bother to read the long 
> list of URLS I provided, listing the large amount of content that are using 
> these features?

Yes; none of them, as far as I could tell, actually showed any real content 
using the functions in question. Sure, there was lots of mention of intranet-
based content using them, but intranets aren't very high on the list of concerns 
here. (Intranet content is much more likely to change in the face of new UA 
requirements than it is to have any affect on UA decisions, as seen by, for 
instance, discussions in XForms contexts. This is especially true here since 
support for the methods in question can be added in the code itself using just 
one line of markup per SVG document, linking to one external script file, the 
contents of which are mostly what you wrote in your patch. This can even be 
trivially done in a way that will use the native methods in other UAs, and use 
the XMLHttpRequest object in UAs that support that instead.)


> If the SVG 1.2 WD continues to CR without change in this area, Mozilla SVG 
> will need to support this in any case if it wishes to be conformant,

You are making a wild assumption here, namely that conformance to SVG 1.2 is an 
interesting goal. Given the resistance that the SVG group is receiving with 
respect to SVG 1.2's scope rapidly spiraling out of control, that assumption is 
a poor one at best. (You yourself have indeed mentioned this in the past.)


> The decision whether to include de-facto standards in Mozilla has always been 
> on the amount of content that already uses it.

Indeed. And in-the-wild Web content at that. So far I have seen less use of 
these features in in-the-wild content than I have seen MNGs.


> please look at any SVG content on the web, tha vast majority will use these.

The onus is on you to prove this.


> Am I to assume that an implementation without this problems would be perfectly 
> acceptable to Mozilla QA?

There's no such entity as "Mozilla QA".

Comment 27

[Jim Ley]

> This is especially true here since 
> support for the methods in question can be
> added in the code itself using just 
> one line of markup per SVG document

So instead of creating an interopable product you expect all authors to make 
the effort to produce special hacks and workarounds to the minority user 
agent?  I'm sure that history has shown that doesn't happen, the minority user 
agent is just ignored.  Mozilla is full of de-facto standards that could be 
dealt with by authors, (document.all as a recent example) history has clearly 
shown that's not relevant.

[On existing content]
>The onus is on you to prove this.

Could you describe a methodology on how I could prove this to your 
satisfaction, I thought a sample from SVGOpen presentations was a good method, 
but you've rejected that one.

Comment 28

[Hixie (not reading bugmail)]

Actually, evidence (e.g. with XMLHttpRequest, with document.all) has shown that 
for this kind of thing, authors _are_ willing to use different codepaths for 
different user agents, especially when it is easy. The recent addition of 
limited document.all support caters for a minority of sites for which 
compatibility with anything but the most popular user agent matters -- a case 
which is irrelevant for SVG given that even the most popular SVG UA is a 
minority UA in this world, and which was only relevant for HTML due to the very 
large number of HTML documents in existence.


> Could you describe a methodology on how I could prove this to your 
> satisfaction, I thought a sample from SVGOpen presentations was a good method, 
> but you've rejected that one.

A sample of real world SVG files (not tests or demos) that use this feature, 
preferably high-profile. For example, for document.all support I believe several 
dozen important sites were found. See, for instance, Bob's work in bug 248549 
(for example comment 55 which shows the volume of data involved in such a 
decision -- he checked some 500 sites).

Comment 29

[David Baron :dbaron:]

The problem, as I see it, is that if you implement it, Web authors will use it,
and you won't be able to change it if the spec changes.

I haven't read the comments above (too many of them), though.

Comment 30

[Jim Ley]

The rebuttal to that point David, is that there are already too many users and 
implementations for the spec to change - if it didn't make it through last call 
it would have to be dropped entirely I'm sure.

The same as any attempt to change other de-facto standards during 
the "ratification" process.

However, I certainly don't have the time to provide the amount of evidence Ian 
requires for this bug, the value to me simply isn't worth it.

Comment 31

[David Baron :dbaron:]

If that's the case, then the SVG community is setting itself up for disaster,
and there's certainly no way it's going to be the cleaner, brighter, new world
that the W3C claims it's going to be.

Comment 32

[Jim Ley]

I'm not sure I understand your comment here David, could you expand?  What's a 
disaster about de-facto standards?  They've been incredibly successful across 
the web.

Or is the disaster, me not having the time to provide the evidence?  That's 
purely a personal issue.  In any case I can't see the relevance to the W3c at 
all.

Comment 33

[David Baron :dbaron:]

No, the disaster is (1) everybody having to reverse-engineer tiny details from
the leading implementation, (2) bugs in the leading implementation that it
refuses to fix even though the Web doesn't really depend on them, but its
clients' "Intranets" do, (3) etc.  The solution, as the CSS group has learned by
experience dealing with the Web (which the SVG group doesn't really have any of,
frankly) is that you need clearly defined behavior, accepted by the community,
including error handling, and thorough test suites, before implementors are
encouraged to start implementing.

Comment 34

[Jim Ley]

>No, the disaster is (1) everybody having to 
>reverse-engineer tiny details from
>the leading implementation,

Which isn't relevant to this discussion, these are 4 de-facto methods, they're 
the only 4 de-facto methods common in SVG.  They're being standardised, thus 
removing the problem.

There's more differences between Mozilla's and IE's XML HTTPRequest 
implementations than there are between ASV, Batiks and even this patches getURL 
implementation.

> (2) bugs in the leading implementation that it
>refuses to fix even though the Web doesn't really 
>depend on them, but its clients' "Intranets" do,

I definately don't see the relevance here, or indeed any such issues that your 
discussing, there are certainly none relevant to these 4 methods.

> (3) etc.  The solution, as the CSS group has learned by
>experience dealing with the Web (which the SVG group 
>doesn't really have any of, frankly)

Interesting Chris Lilley (SVG WG Chair) and Ian Hickson - who claims to be a 
member of the SVG WG (I don't know of course, the membership lists aren't 
public) have both experience of both CSS and SVG, so if CSS experience is 
valuable I think it has it.

> is that you need clearly defined behavior, 
>accepted by the community, including error 
>handling, and thorough test suites, before 
>implementors are encouraged to start implementing.

That certainly describes SVG well, what you're missing is that these are de-
facto standards that the SVG WG are including to ensure there is a clear 
definition.  Just as the WHAT-WG are doing with the XML HTTP Request object - I 
cannot see a single difference between the situations.

Comment 35

[Hixie (not reading bugmail)]

(I am not an active member of the SVG working group; my membership is purely a 
technicality intended to get around W3C process rules so that I can be an sXBL 
specification editor.)

Comment 36

[Hixie (not reading bugmail)]

> these are 4 de-facto methods, they're the only 4 de-facto methods common in 
> SVG.  They're being standardised, thus removing the problem. 
> There's more differences between Mozilla's and IE's XML HTTPRequest 
> implementations than there are between ASV, Batiks and even this patches 
> getURL implementation.

The naivety of this statement amply demonstrates David's point, I think.

Comment 37

[Brendan Eich [:brendan]]

Jim:

> I don't understand the comment Brendan, you're saying de-facto standards are
> pefectly appropriate for Mozilla to include, yet this enhancement was marked
> invalid - yet it's an implementation of a de-facto standard just as the
> xmlhttprequest is

I didn't say a thing about this bug being INVALID, and I didn't mark it so. 
Please respond to what I wrote, not what Ian wrote, when addressing me.

You repeatedly compare de-facto standards used by millions of web pages, and
supported by the >90% market share HTML UA, as well as by the top two or three
minority-market-share UAs, to a handful of SVG DOM (or BOM, whatever) extensions
that I've never heard of till this bug.

That's a pretty bogus comparison.  "De-facto" when applied to web standards does
not mean "whatever Adobe (or Batik, etc.) implemented" -- especially if the
so-called standard is undertested and underused on the web.  "De-facto" applied
to "web standard" means something than any competent modern web browser will
need to implement.

I agree with bsmedberg and dbaron about SVG1.2, and I'm not going to spend any
more time on it, or on attempts to jump the CR gun, right now.  The SVG owner
and peers should weigh in here.

/be

Comment 38

[tor]

*** Bug 301449 has been marked as a duplicate of this bug. ***

Comment 39

[kouejou]

(In reply to comment #38)
> *** Bug 301449 has been marked as a duplicate of this bug. ***

I use Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531
Firefox/1.0+

the function printNode work correctly but other function parseXML not work.

the function parseXML stop my exécution. I dont know why did not work.

please i wait any subjection.

thanks

Comment 40

[kouejou]

I use Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531
Firefox/1.0+

That is the code svg i try to execute:

<?xml version="1.0" ?>
<svg id="root" xmlns="http://www.w3.org/2000/svg" width="200" height="200" >

<script><![CDATA[
    function charge(evt){
	alert("charge");
	svg=evt.target.ownerDocument;
	svgRoot=svg.getElementById("root");
	node=parseXML(svg);
	svgRoot.appendChild(node);
    }
    function  parseXML (doc) {
   	doc2=(new DOMParser()).parseFromString("<rect x='100' y='100' width='50'   
          height='50' fill='green' />","text/xml");
    	doc.importNode(doc2,true);
    	return doc2;
    
   }
]]>
</script>
<rect x="10" y="10" width="50" height="50" fill="red"  onclick="charge(evt)"/>
</svg>

I have all time that Error: uncaught exception: [Exception... "Node cannot be
inserted at the specified point in the hierarchy"  code: "3" nsresult:
"0x80530003 (NS_ERROR_DOM_HIERARCHY_REQUEST_ERR)"  location:
"file:///C:/Documents%20and%20Settings/alkante/Bureau/Essai.svg Line: 10"].

Please cant you help me.

how can i use the function parseXML for appendChild the node
thanks

Comment 41

[Brendan Eich [:brendan]]

(In reply to comment #40)
>     function  parseXML (doc) {
>    	doc2=(new DOMParser()).parseFromString("<rect x='100' y='100' width='50'   
>           height='50' fill='green' />","text/xml");

Space on both sides of assignment operator would be nice.

Also, you need not parenthesize new DOMParser() to have the right precedence.
Just write:

   	doc2 = new DOMParser().parseFromString("<rect x='100' y='100' width='50'   

Sorry for the nits, hope they are useful.

/be

Comment 42

[kouejou]

I wait answers of last question. i don't know if the function parseXML is correct.
I can't use the result in this function to  insert the element in my document svg.

this problem affect my work. please if anybody has solve the same problem please
i will be very happy to find the solution of this problem.

thanks

Comment 43

[kouejou]

i resolve my problem.

thanks

Comment 44

[Holger Will]

so for everyone who has the same problem as kouejou,
the string with the rect does not contain a namespace, 
so it gets parsed into the null namspace, since that it
is not visible after appending.

so adding a namespace solves the problem.
doc2 = new DOMParser().parseFromString("<rect xmlns="http://www.w3.org/2000/svg"
x='100' y='100' width='50' height='50' fill='green' />","text/xml");

sorry for the spam, i know this is not a forum for this kind 
of discussion ;-)