Re: Proposal for a page visibility API
On Thu, Jan 20, 2011 at 12:50 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, Jan 20, 2011 at 2:36 PM, Alex Komoroske komoro...@chromium.orgwrote: If you intend preview to include large but smaller-than-full-size previews, eg. scaled to 50%, I'd recommend avoiding the word thumbnail; I think most people wouldn't consider that a thumbnail. (I could probably come up with a reasonable UI where a preview is at 100%, too...) I agree, although I'm struggling with the precise wording to replace that description with. Do you have any suggestions? I did, too. The main generality behind previews that I came up with is that they're not actually the real, interactive page; they're more like a picture of the page than the page itself (eg. moving the mouse over it won't trip any mouseovers)--but that's far too complicated to get into for a description that should be simple and generalized. How about: “preview” : the page may be at least partially visible, but not in an interactive form (e.g. a lower-resolution thumbnail when switching between tabs). visibilitychange A simple event, fired at the document object immediately after document.visibilityState transitions between visibility states. The event has a property, fromState, that is set to the value of document.visibilityState just before it was changed to the current value. Note that visibility has nothing to do with whether the document’s contents have fully loaded or not, which implies that for any given visibility transition event, onload may or may not have already fired. This should also include the old document.visibility value. Agreed, but what should the property of the event be called? fromVisible seems awkward. wasVisible is more natural, but it may be inconsistent to use both from and was in the same event. I'm not sure if there are any precedents to follow... I have a moderate preference for wasVisible given the extreme awkwardness of fromVisible On Thu, Jan 20, 2011 at 6:47 AM, Boris Zbarsky bzbar...@mit.edu wrote: So an iframe that's scrolled out of view could return hidden if the browser wants? That's probably bad: if you're in a hidden iframe, you likely want to know if the document you're in is visible, not to always think you're hidden. I think that's right. I'll add language that makes it clear it's the top-most containing page visibility. If in the future there are valid use cases for an iframe to know when it's hidden within its visible parent or scrolled off screen, we could provide an additional visibility state in the second (optional) set of return values for document.visibilityState that can be used for this case. -- Glenn Maynard
Re: Proposal for a page visibility API
On Thu, Jan 20, 2011 at 2:02 AM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jan 19, 2011 at 9:22 PM, Alex Komoroske komoro...@chromium.orgwrote: Use cases * A page wants to detect when it is being prerendered so it can behave appropriately. * A puzzle game has a timer that keeps track of how long the user has taken to solve the puzzle. It wants to pause the timer when the user has hidden the tab. * A web app that uses polling to fetch dynamic content can pause polling when it knows the page is hidden from the user. * A streaming video site doesn’t want to start the video until the user actually views the tab for the first time (i.e. video shouldn’t start automatically if a user opens the tab in the background). Another example of this use case: a browser session is restored with many tabs. As with loading a link in a background tab, video shouldn't start playing. I've lost count of the number of times I've reloaded my browser and had a YouTube video or three start playing (somewhere among my three browser windows and around 60-80 tabs). Note that the Flash videos on http://www.ted.com do load paused if they're loaded in the background, which is very helpful; I can middle-click lots of videos in the video index into background tabs, and then view them one at a time. It should be possible to implement this for HTML5 video. The same applies to anything that plays sound, like games--they shouldn't start immediately when they're in a background tab on load. Agreed, these are common and valuable use cases. * Values returned by all conforming implementations * “visible” : the full-size page content may be at least partially visible on at least one screen. More simply, the full-size page content may be at least partially visible. Agreed. Changed. * “hidden” : the full-size page content is not visible to the user at all. * Additional values potentially returned by some implementations in some cases * “prerender” : the page is currently being loaded off-screen and might never be shown to the user. * “cache” : the page is currently “frozen” in a cache and not displayed on screen (e.g. the back-forward cache). * “preview” : the page is currently visible only in a lower-resolution thumbnail. I think that at least visible and hidden should be explicitly defined as having document.visible true and false, not technically left implementation-defined. Defining prerender and cache as false is probably good too, if their descriptions specifically say off-screen. Agreed, and changed. If you intend preview to include large but smaller-than-full-size previews, eg. scaled to 50%, I'd recommend avoiding the word thumbnail; I think most people wouldn't consider that a thumbnail. (I could probably come up with a reasonable UI where a preview is at 100%, too...) I agree, although I'm struggling with the precise wording to replace that description with. Do you have any suggestions? visibilitychange A simple event, fired at the document object immediately after document.visibilityState transitions between visibility states. The event has a property, fromState, that is set to the value of document.visibilityState just before it was changed to the current value. Note that visibility has nothing to do with whether the document’s contents have fully loaded or not, which implies that for any given visibility transition event, onload may or may not have already fired. This should also include the old document.visibility value. Agreed, but what should the property of the event be called? fromVisible seems awkward. Thoughts and comments are welcome. I think is very important information to make available to scripts. Just to make my agreement complete, I'll point out that I agree about this, as well. :-) -- Glenn Maynard
Re: Proposal for a page visibility API
On Thu, Jan 20, 2011 at 2:51 AM, Charles McCathieNevile cha...@opera.comwrote: On Thu, 20 Jan 2011 03:22:29 +0100, Alex Komoroske komoro...@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.
Re: Proposal for a page visibility API
For clarity, I've included the current draft of the proposal below, which incorporates the feedback from this thread. There is currently no good way for a web page to detect that it is completely invisible to the user (for example, that it is a background tab), although some imperfect heuristics do exist. In the future, there may be cases where such detection is even more important, for example in the prerendering feature that Chromium is currently in the early stages of experimentation with. Use cases * A page wants to detect when it is being prerendered so it can behave appropriately. * A puzzle game has a timer that keeps track of how long the user has taken to solve the puzzle. It wants to pause the timer when the user has hidden the tab. * A web app that uses polling to fetch dynamic content can pause polling when it knows the page is hidden from the user. * A streaming video site doesn’t want to start the video until the user actually views the tab for the first time (i.e. video shouldn’t start automatically if a user opens the tab in the background). * An in-browser collaborative editing environment wants to update a user’s status to away when the editing surface is not visible to the user. * A web-based chat application wants to show the user notifications via the Web Notification API when a message is received, but only when the page is not visible to the user. With these use-cases in mind, there are a number of requirements. Requirements * Easy for developers to write scripts that fall back on old behaviors for browsers that do not implement this API * Ability to query the document’s current visibility state * Events fired when the document transitions between visibility states * Ability for browser vendors to add new visibility states in the future API document.visible Returns true if document.visibilityState’s current value is in the set of visibility states considered to be visible (see the next section for information on document.visibilityState). In practice document.visible is merely a convenience property that is well-suited to simple uses. The “visible” state is considered to be visible in all implementations. “hidden”, “prerender”, and “cache” are considered to be hidden in all implementations. The visibility of additional values, including “preview”, are up to the discretion of the implementation (for example, an implementation that makes use of nearly-full-size thumbnail previews may consider “preview” to be a visible state). document.visibilityState A read-only property that returns a string, one of the values described in the next section. Developers can use the existence of this property to know that they can rely on the rest of this API, too. * Values returned by all conforming implementations * “visible” : the page content may be at least partially visible. * “hidden” : the page content is not visible to the user at all. * Additional values potentially returned by some implementations in some cases * “prerender” : the page is currently being loaded off-screen and might never be shown to the user. * “cache” : the page is currently “frozen” in a cache and not displayed on screen (e.g. the back-forward cache). * “preview” : the page is currently visible only in a lower-resolution version. Visibility states considered to be visible, for the purposes of document.visible, include “visible”. States in the second set are not guaranteed to be returned in all cases where they might otherwise appear to apply--it is left to the discretion of the implementation. Additional return values may be added to this API in the future. It is up to the implementation to interpret what these values mean in the precise context of interface and platform. As an example, a current-generation desktop browser might interpret the values the following way: “visible” : the tab is focused in its non-minimized window (regardless of the focus state of the containing window). “hidden” : the tab is backgrounded within its window, or the containing window is minimized. visibilitychange A simple event, fired at the document object immediately after document.visibilityState transitions between visibility states. The event has two properties, fromState and fromVisible, that are set to the value of document.visibilityState and document.visible, respectively, just before they were changed to the current value. The eventNote that visibility has nothing to do with whether the document’s contents have fully loaded or not, which implies that for any given visibility transition event, onload may or may not have already fired.
