W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2013

Re: [whatwg] Specify getSVGDocument

From: Erik Dahlström <ed@opera.com>
Date: Tue, 19 Nov 2013 18:31:51 +0800
Message-ID: <CAK-_kYBmHZgDgsroTgnbVqR_vYrn-85N_1E=opH5peQjXFMoYg@mail.gmail.com>
To: WHATWG <whatwg@lists.whatwg.org>
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

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:

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

> On Mon, Nov 18, 2013 at 8:02 PM, Boris Zbarsky <bzbarsky@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
Received on Tuesday, 19 November 2013 10:32:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:14 UTC