W3C home > Mailing lists > Public > public-svg-wg@w3.org > April to June 2009

Re: "Clarify getSVGDocument behavior" erratum

From: Erik Dahlstrom <ed@opera.com>
Date: Fri, 15 May 2009 08:46:53 +0200
To: "Cameron McCormack" <cam@mcc.id.au>, public-svg-wg@w3.org
Message-ID: <op.utyk4fimgeuyw5@blorp.xn--dahlstrm-t4a.net>
On Fri, 15 May 2009 07:30:55 +0200, Cameron McCormack <cam@mcc.id.au>  

> Hi WG.
> I was going through the SVG 1.1 errata document today, getting it
> prepared for publication.  Looking at
> http://www.w3.org/2003/01/REC-SVG11-20030114-errata#clarify-getsvgdocument-behavior
> I’m not happy with the current replacement wording, which is:
>   This method must return the Document object of embedded content in an
>   embedding element, or null if there is no document.
>   Informative Note: This is a legacy method equivalent to
>   contentDocument, and may not always return an SVG Document. The author
>   should check the namespaceURI or the root node tag name before using
>   the returned document.
> The getSVGDocument() operation is defined to return an SVGDocument, so
> it’s not possible to conform to the IDL and return a Document that isn’t
> an SVGDocument.
> I think we should either change the return type to be Document, or
> define that it returns null if the document isn’t an SVG document.

Changing getSVGDocument to return a Document would be better, the  
alternative might be confusing to authors (especially given that people  
already use these methods interchangably because of browser variations).

> Also, the wording about implementing this on HTML <object> DOM objects
> has been lost.  Without it, nothing implements this interface.

We could add that part back, or we could perhaps link to the definition of  

> If we are really not interested in it being implemented (since, as Anne  
> points
> out, you would typically use contentDocument in a browser), then perhaps
> we can just drop the interface altogether.

I think it'd be good to move away from getSVGDocument, but I wonder if  
removing it at this point is good. We would have to add the definition of  
the contentDocument attribute in SVG then (new feature?) since we can't  
reference any spec for it AFAIK (not in CR/REC).

I'd be very happy indeed if we could require the EmbeddingElement  
interface instead of getSVGDocument, however it seems like the  
<html:embed> element doesn't offer this interface. I think it would be  
better to do this change in SVG 2.0.

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Friday, 15 May 2009 06:48:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC