- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 05 Apr 2006 17:54:00 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Maciej Stachowiak <mjs@apple.com>, Web APIs WG <public-webapi@w3.org>
>> To summarize options: >> >> 1) Require any non-presented DocumentWindow to have a null defaultView. >> 2) Allow a non-presented DocumentWindow to have any AbstractView or null as >> the defaultView (essentially, we disclaim stating a requirement on >> non-presented documents). >> 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. > > I am extremely against not specifying this (option 2), as I am against > not specifying anything that authors could end up relying on. The problems with 3 are: * It doesn't allow transitions between presented and non-presented, this transition already happens today, and it would be bad to restrict new features such as allowing a document to become presented after-the-fact * It means that implementations has to double the number of document classes. * It means that the parser has to be aware of if the document is going to be presented or not. So I think 1 is the way to go. Alternativly: 4) Require that the defaultView is not a Window (and, if we add it, parentWindow must be null). / Jonas
Received on Thursday, 6 April 2006 00:54:11 UTC