RE: GetSVGDocument interface

Hi Cameron,

Yes, your testing seems to end up with similar results to my own of a few years ago.

The trouble a few years ago, was that ASV had (by an order of magnitude) the broadest support of the SVG spec, and it only allowed <embed> if you wanted to work with scripting between HTML and SVG -- hence, my widespread encouragement of getSVGDocument over contentDocument. With most (but not all) modern browsers starting to catch up or (in two cases) surpass ASV, ASV's relevance has declined to the point that even I (who needed it to test odd mixtures and piles of features) would now consider it to be passé. * Hence, with time, people will move toward contentDocument, but in the meantime, there will be things that break. People have been reading books and looking at collections of working examples and that establishes inertia. I guess the question of how to transition out old things in favor of new things is a question of ideological purity (specs should be clean) versus pragmatics (specs should not live independent of the people who use them -- whence HTML5 instead of XHTML). If I were a browser developer would I want to intentionally break the web just because a spec mandates it? Probably not. Nor would I want to support obsolete or bad practices in perpetuity. Specs must move forward and things will become obsolete and old things will break -- that is just how it is. The timing is what matters, I suppose.

Just keep in mind that the bulk of the SVG WG represents implementers (and the W3C which is supported by implementers), so consider those few authors and teachers who do try to listen and speak up from time to time as possibly representing more opinions than our voices might indicate at first glance! Maybe we should move slowly in that direction, so that a second edition of the new crop of SVG books** have a chance to emerge.

Regards
David



* For weird things like animated clipPaths within ClipPaths applied to regions affected by complex (and animated) filter chains, it may still be the only one that does it right!
** Actually I suppose the new books probably got contentDocument correct, I can't remember, but there are a couple of things that ya'll broke in the past couple of months that caused my blood pressure to rise. 

-----Original Message-----
From: Cameron McCormack [mailto:cam@mcc.id.au] 
Sent: Tuesday, August 21, 2012 8:56 PM
To: SVG public list
Subject: Re: GetSVGDocument interface

Cameron McCormack:
> Do we need to keep this interface, which has the getSVGDocument() 
> method on it, and which was intended to be implemented on interface 
> like HTMLObjectElement?  It's entirely redundant with contentDocument. 
> Unless people think content is using it, we should drop it.

Did some testing:

   http://people.mozilla.org/~cmccormack/tests/svg-content-document.html

and consistently across Firefox, IE, Chrome, Safari and Opera, both contentDocument and getSVGDocument work on <object> and <iframe>, and for <embed> only getSVGDocument exists.  In line with what Erik said.

My impression previously was that getSVGDocument wasn't implemented as widely as it seems it is.

Received on Wednesday, 22 August 2012 02:27:12 UTC