- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 5 Apr 2006 03:24:25 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Ian Hickson <ian@hixie.ch>, Web APIs WG <public-webapi@w3.org>
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). Regards, Maciej
Received on Wednesday, 5 April 2006 10:24:40 UTC