RE: [PageVisibility] specific visibility states

Operating systems decide how these minimized preview states work, whether the visual representation of the tile is updating (or a cached bitmap for example), whether the user can interact with the preview, etc. I don't believe we should go down the path of trying to represent all of these states.

If we focus on the primitives (visible, hidden, etc.) user agents and operating systems can map these primitives as best possible to the experience they want to provide. And then in places where an operating system wants to represent more specific individual states, for example the WebOS preview cards mentioned, that could do that through a vendor prefixed API.

Hidden and visible are the two clear primitives for me. 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.

The trick is finding the right primitives without adding to much complexity.



-----Original Message-----
From: Kyle Simpson [mailto:getify@gmail.com] 
Sent: Sunday, May 01, 2011 11:56 PM
To: Jason Weber; Cameron McCormack; public-web-perf@w3.org
Subject: Re: [PageVisibility] specific visibility states

> From our discussion at the F2F, my understanding was that the 
> PAGE_PAGE_PREVIEW state was intended to capture the scenario where the 
> page is in some preview form and not intractable. For example 
> minimized into a dock or tile of some type. It indicates the page is 
> visible in some smaller preview state.

Is the reasoning behind this that the site would do something *different* than it would if it were in the hidden state? Like are you suggesting a site would modify its own rendering state to account for the fact that it was in a preview state, and perhaps even show/hide alternate content? That's seems like quite a stretch of likelihood as a use-case. Seems to me that a page is either fully visible, or not visible at all... this in-between stuff seems like getting too deep in the weeds.


> I personally don't believe we need the PAGE_TASKBAR_PREVIEW state. 
> This came out of the F2F discussion, and was intended to cover the 
> scenario where the page is in a preview form but still possibly 
> animating or intractable like what you see in the Windows 7 taskbar.

Again, is the suggestion that a site would somehow modify its animations or interactivity to still be present but more limited or something, when its in this special mostly-minimized-but-still-visible-and-interactive-operating
mode? I don't see any reason why a site would want to display some different content (or interactivity/animations) in this mode compared to full mode (and just letting the OS scale down the actual screen real estate display of it).

Consider the "card" metaphor that mobile WebOS uses for a moment... are we suggesting that a web page would somehow alter its display/functionality when the card is scaled down while you are thumbing between cards? I think that would be much more annoying to users if the content didn't just scale down but actually changed itself. I don't see any reason why we should go down the road of setting that precedent or supporting it.


--Kyle

Received on Monday, 2 May 2011 14:27:57 UTC