Closed
Bug 262166
Opened 20 years ago
Closed 13 years ago
Enhancement patch for supporting printNode, parseXML, getURL and postURL in SVG documents.
Categories
(Core :: SVG, enhancement)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jim, Assigned: jim)
References
Details
Attachments
(2 files, 3 obsolete files)
561 bytes,
patch
|
Details | Diff | Splinter Review | |
2.98 KB,
patch
|
Details | Diff | Splinter Review |
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.
Updated•20 years ago
|
Assignee: general → jim
Updated•20 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #160549 -
Attachment is obsolete: true
Attachment #160552 -
Flags: review?
Attachment #160554 -
Flags: review?
Comment 4•20 years ago
|
||
SVG 1.2 is not yet in candidate recommendation.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
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.)
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 6•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
(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•20 years ago
|
||
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.
(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).
Assignee | ||
Comment 11•20 years ago
|
||
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?
Assignee | ||
Comment 12•20 years ago
|
||
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•20 years ago
|
||
(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. :-)
Assignee | ||
Comment 14•20 years ago
|
||
changes as per review.
Attachment #160554 -
Attachment is obsolete: true
Assignee | ||
Comment 15•20 years ago
|
||
Changes as per review
Attachment #160552 -
Attachment is obsolete: true
Comment 16•20 years ago
|
||
> 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•20 years ago
|
||
> 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.
Assignee | ||
Comment 18•20 years ago
|
||
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?
Assignee | ||
Comment 19•20 years ago
|
||
Ian, could you provide a link to those W3 rules? Cheers,
Comment 20•20 years ago
|
||
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.
Assignee | ||
Comment 21•20 years ago
|
||
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.
Assignee | ||
Comment 22•20 years ago
|
||
* 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•20 years ago
|
||
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".
Assignee | ||
Comment 24•20 years ago
|
||
"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•20 years ago
|
||
> 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•20 years ago
|
||
> "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".
Assignee | ||
Comment 27•20 years ago
|
||
> 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•20 years ago
|
||
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).
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.
Assignee | ||
Comment 30•20 years ago
|
||
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.
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.
Assignee | ||
Comment 32•20 years ago
|
||
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.
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.
Assignee | ||
Comment 34•20 years ago
|
||
>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•20 years ago
|
||
(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•20 years ago
|
||
> 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•20 years ago
|
||
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•19 years ago
|
||
*** Bug 301449 has been marked as a duplicate of this bug. ***
Comment 39•19 years ago
|
||
(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•19 years ago
|
||
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•19 years ago
|
||
(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•19 years ago
|
||
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•19 years ago
|
||
i resolve my problem. thanks
Comment 44•19 years ago
|
||
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 ;-)
Updated•15 years ago
|
QA Contact: ian → general
Updated•15 years ago
|
Attachment #160552 -
Flags: review?
Updated•15 years ago
|
Attachment #160554 -
Flags: review?
![]() |
||
Updated•13 years ago
|
Status: REOPENED → RESOLVED
Closed: 20 years ago → 13 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•