- From: Jason Weber <jweber@microsoft.com>
- Date: Mon, 2 May 2011 15:39:35 +0000
- To: Kyle Simpson <getify@gmail.com>, Cameron McCormack <cam@mcc.id.au>, "public-web-perf@w3.org" <public-web-perf@w3.org>
Good feedback. What are your thoughts on the prerender state Kyle? -----Original Message----- From: Kyle Simpson [mailto:getify@gmail.com] Sent: Monday, May 02, 2011 8:22 AM To: Jason Weber; Cameron McCormack; public-web-perf@w3.org Subject: Re: [PageVisibility] specific visibility states > The prerender and preview states are not quite as clear, but these are > important to performance and I think should be included. As mentioned > I think we should pull the taskbar state which feels duplicative and > platform specific. > > In the preview state the site may choose to do less work, thus > impacting performance/power. Using the email example I provided > earlier, if a site knew it was in a preview state it may contact the > server less frequently or only update the DOM when the state changes. My point before was, what's the thought process on how the site would do a *different* thing between the "fully hidden" state and the "I'm not entirely visible" (aka "preview") state? It seems most reasonable to me that the site would simply go into "low consumption" mode for either, and not that it would do different things between preview and fully-hidden. In fact, aren't most use cases for "preview" pretty transitory rather than a site persistently sitting for long periods of time in the "previewed" state? If the site is in "preview" state for a brief second while switching between tabs, there's not much of a performance case to be made for the site trying to quickly switch into some other mode of functionality, only to go right back to the "fully hidden" mode. As far as I feel, the preview state that certain OS's can put a site into (including the non-interactive preview AND the interactive/operational win7 taskbar-preview) should just map to the same behavior (from a performance perspective) as the fully-hidden state. Which means we only need one state, which all of those cases would receive. In other words, I don't see any value in giving a site an API to let it know it's in these special in-between preview states. It's either "fully-visible" or "not fully visible", and the site can decide what to do as appropriate. I'm specifically saying I think the semantics of calling the state "hidden" and "visible" are the problem, because it leads to ask the question about the gray-area in-between. If we change the semantics of these state names to be "Fully Visible" or "Not Fully Visible", we can simplify it down to only those two states and cover all the important bases. --Kyle
Received on Monday, 2 May 2011 15:40:05 UTC