[whatwg] Specify getSVGDocument

[Erik Dahlström]

SVG 1.1 Second Edition deprecated .getSVGDocument(), and made it an alias
for .contentDocument essentially yes.

SVG2 has not yet seen any edits related to this method. But it's not
unlikely that SVG2 will drop it given that SVG 1.1 states: "This interface
is deprecated and may be dropped from future versions of the SVG
specification".

It's possible that .getSVGDocument() is still in use due to <embed>
elements not supporting .contentDocument, and people wanting to allow the
use of plugins for svg content in case there was no native svg support in
the browser. This may have changed due to the Adobe SVG plugin not being
supported anymore.

An example:
http://xn--dahlstrm-t4a.net/svg/html/get-embedded-svg-document-script.html
/ed



On Tue, Nov 19, 2013 at 5:33 AM, Philip Jägenstedt <philipj at opera.com>wrote:

> On Mon, Nov 18, 2013 at 8:02 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> > On 11/18/13 1:37 PM, Philip Jägenstedt wrote:
> >>
> >> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2643
> >>
> >> In my testing, getSVGDocument is supported on <embed>, <frame>,
> >> <iframe> and <object> in Firefox Nightly, IE11 Preview, Safari 7.0 and
> >> Opera 12.16, the only exception being frame.getSVGDocument in Firefox.
> >>
> >> I don't know if this API is actually useful, but since it's already
> >> implemented everywhere it should probably be spec'd.
> >
> >
> > SVG2 is trying to spec it, afaict, as basically an alias for
> > .contentDocument.  It _would_ make more sense to do that in HTML, I
> agree.
>
> Indeed, since it's actually on the HTML*Element interfaces. SVG2 can
> do partial interfaces, of course, but that makes it a bit harder to
> actually find.
>
> Philip
>