- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 6 Apr 2006 15:35:57 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, Ian Hickson <ian@hixie.ch>, Web APIs WG <public-webapi@w3.org>
On Apr 5, 2006, at 5:39 PM, Jonas Sicking wrote: > Boris Zbarsky wrote: >> Ian Hickson wrote: >>>> 3) Forbid any non-presented Document to implement DocumentWindow >>>> (seems too >>>> restrictive). >>> >>> I am strongly in favour of 3. If we don't do 3, we're going to >>> have to require a whole heck more than 1 -- we're going to have >>> to special case every single API that requires a rendering context. >> What happens when a document goes from "presented" to "non- >> presented" or vice versa? >> And note that even if we disallow such transitions doing what you >> propose would require that all document creations know whether the >> document is going to be presented..... This could be a pretty >> heavy burden in some cases. > > Actually, it already does happen in some cases. If you hold on to a > document inside an iframe and then navigate away from the document > the document goes from being presented to being non-presented. Presumably, back/forward cache plus holding onto a document from another window could result in the inverse transition. I discussed this with Ian on IRC and he agreed (I think) that non-presented documents should be allowed (perhaps even required) to implement DocumentWindow in a Window UA, and that their attributes should be appropriately neutered. So if we elimitate 3 and 2, that only leaves 1, require defaultView (and probably other attributes like location) to be null for documents that implement DocumentWindow but are not presented. BTW the frame thing is a handy portable way to get a non-presented document that implements DocumentWindow for testing purposes. Regards, Maciej
Received on Thursday, 6 April 2006 22:36:16 UTC