- From: Alex Komoroske <komoroske@chromium.org>
- Date: Thu, 20 Jan 2011 12:04:07 -0800
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: public-webapps@w3.org
- Message-ID: <AANLkTi=Vvmc=C1pUa7eHAZbWBAHMBwU75bFFUJTrFh+O@mail.gmail.com>
On Thu, Jan 20, 2011 at 2:51 AM, Charles McCathieNevile <chaals@opera.com>wrote: > On Thu, 20 Jan 2011 03:22:29 +0100, Alex Komoroske <komoroske@chromium.org> > wrote: > > Use cases >> > > * An app can provide notifications (using the Web Notification stuff that > is under developemnt) when it is not visible/focused, but skip them when it > is to minimise distractions and reduce cognitive load > Great use case, I'll add this to the list. > * An application can (try to) communicate with the currently focused > application. This is essentially what a whole class of extensions does in > practice. Enabling it for general HTML would be a step towards making it > possible to share different functionality extensions. Right now, it would > rely on out-of-band agreement about how to communicate, but that is > perfectly feasible in practice. It also introduces a clear requirement for a > security discussion (see the paper that Art posted recently...). Although I think this is an interesting and valid use case (and one, as you point out, that has many examples in practice today), I think it has the potential to complicate this proposal, especially regarding security (again, as you note). Is there a way to design this API in a way that makes the additional functionality fit in better in some future proposal? > > > The idea that a thumbnail, or popup, can mean that more than one document > is visible is interesting. > Agreed. The bulk of the discussion on the what-wg list centered around what, precisely, it meant to be visible. We identified a number of interesting cases, like the preview features that some browsers implement today. Other complexities include multiple screens and windows that are partially or completely obscured by other windows. That led to the current wording of this proposal, which is deliberately somewhat vague and interface-concept agnostic, and only provides a strong guarantee that, if the API says you're hidden, you are definitely hidden. (However, note that it is possible for the API to report that you're visible when in practice you aren't, e.g. when your window is completely obscured by another window.) > > In our API we have getFocused() (which mostly does what it says on the box, > although certain special tabs don't respond to it) > > > document.visibilityState >> >> A read-only property that returns a string >> > > It would make sense to have this relate to the ViewModes stuff that was > originally developed for widgets, no? Based on my reading of the view-modes in the widgets spec, I don't think they relate particularly closely. View-mode seems to be a request from the app for a specific type of display, whereas this API proposes a way for a page to query its visibility but not request a change in visibility. Also note that the specific UI concepts of "fullscreen", "windowed", etc are deliberately avoided by this API for the reasons that I referenced above from the what-wg thread.
Received on Thursday, 20 January 2011 20:04:59 UTC