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
