W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: ISSUE-66: should Documents that aren\'t being presented be required to have a null defaultView?

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 5 Apr 2006 03:24:25 -0700
Message-Id: <5B04A931-995E-414D-B568-A8BDA3E4BB21@apple.com>
Cc: Ian Hickson <ian@hixie.ch>, Web APIs WG <public-webapi@w3.org>
To: Jonas Sicking <jonas@sicking.cc>

On Apr 5, 2006, at 2:40 AM, Jonas Sicking wrote:

> Ian Hickson wrote:
>> In any case if we want to _allow_ Document to implement  
>> DocumentWindow even when there's no Window, we should just require  
>> it, and be done with it. I don't want to end up in a situation  
>> where some browsers have it and some browsers don't.
> We definitely want to allow all Documents to implement  
> DocumentWindow. I don't want to have two versions of every document  
> class and have to worry about constructing the right one.

I agree that it should be allowed. But I am not sure it should be  
required, and I can't imagine how to test an implementation against  
such a conformance requirement, as there is no exhaustive list of  
ways to get a Document and nothing stops UAs from inventing new ones.

> Another argument is that it would be useful to be able to stick  
> such a Document inside a window (using some as-of-yet undefined  
> api) and have it displayed and at that point the Document should  
> definitely implement DocumentWindow.

Agree on both of these.

> This doesn't say anything about what the properties of an non- 
> presented window should be though. I agree that it might be bad to  
> *require* defaultView to be null unless we can come up with a good  
> reason for it.

It has some slight benefits:

- Easy to tell whether a document is being presented.
- One less thing for UAs to potentially disagree on.

The real question is, is there a use case for this? The only use case  
that would be affected is the ability to have a Document that  
implements DocumentWindow and has a default view that does not  
implement Window. If its defaultView is a Window, then arguably it is  
being presented in a browsing context, however invisibly. So is that  
a particularly compelling use, to have a defaultView that isn't a  
Window in an implementation that supports Window?

> Maybe what we should say is that "defaultView *can* be null, for  
> example if the document doesn't have a presentation"?

It can be null *only* in the case that the document doesn't have a  
presentation (or more specifically isn't being presented in a  
browsing context), we certainly don't want to open the doors to it  
being null on a window's document.

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).

Received on Wednesday, 5 April 2006 10:24:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC