RE: GetSVGDocument interface

Lots of people have been taught (as the outcome of extensive experimentation
at the time) that contentDocument was inconsistent across browsers as well
as across methods of retrieval (embed, object, iframe, inline, HTML5, etc.).
Removing something from the spec hopefully does not mean removing support
from it from browsers. That would cause trouble for a decade or so. Specs
are really just sort of guidelines (as per Captain Barbossa) aren't they?


-----Original Message-----
From: Bjoern Hoehrmann [] 
Sent: Tuesday, August 21, 2012 7:04 AM
To: Cameron McCormack
Cc: SVG public list
Subject: Re: GetSVGDocument interface

* Cameron McCormack wrote:
>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.

Well, it was added because there was no adequately defined and implemen- ted
alternative available at the time, and making the current version of I ended up using an <iframe> and `.content-
Window.document` because none of the other alternatives I tried worked.

If some implementations drop it because it's been dropped from the spec,
that would be yet another case to consider when working around bugs, so I
think there should be some evidence presented that `.contentDocument` is
actually always available where needed or convenient these days.
Björn Höhrmann · · Am
Badedeich 7 · Telefon: +49(0)160/4415681 ·
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · 

Received on Tuesday, 21 August 2012 12:14:56 UTC