W3C home > Mailing lists > Public > public-web-perf@w3.org > May 2011

Re: [PageVisibility] specific visibility states

From: Kyle Simpson <getify@gmail.com>
Date: Mon, 2 May 2011 10:22:15 -0500
Message-ID: <8CA2894CC58A47F49E1B27D95636CFD2@spartacus>
To: "Jason Weber" <jweber@microsoft.com>, "Cameron McCormack" <cam@mcc.id.au>, <public-web-perf@w3.org>
> 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.


Received on Monday, 2 May 2011 15:23:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:30 UTC