RE: [PageVisibility] specific visibility states

I share many of the same concerns. This is a unique specification in that every platform has different scenarios around window management and visibility. I recommend we find way to generalize the primitive visibility states and allow the user agents to make the right decisions for the different platforms they support. I would like to avoid the situation where we're trying to spec every corner case.

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.

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. Jatinder captured in the spec for completeness and it's one of the things we wanted to discuss. Our thinking is that the user agent can accurately capture this state through "visible" and "preview" depending on the scenario.

Thanks, Jason


-----Original Message-----
From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Cameron McCormack
Sent: Sunday, May 01, 2011 9:46 PM
To: public-web-perf@w3.org
Subject: [PageVisibility] specific visibility states

It seems to me that the descriptions of the visibility states reported in visibilityState are very specific and not necessarily applicable to a wide variety of platforms and modalities.  For example:

  visible attribute
    This attribute returns true when the User Agent is not minimized and
    the page is on a foreground tab.

Certainly there are UAs that don’t have the concept of window minimisation, such as Safari on iOS devices.  I think the wording just needs to be made a bit more generic, with minimisation and background tabs cited as examples of the `visible == false` case.

Would pressing ⌘H to hide an application’s windows on Mac OS make `visible == false`?  The window isn’t minimised, one of the pages would still be in the foreground tab, it’s just that the window isn’t being shown.  Cases like this would benefit from more general language.

  The attribute returns false when:
    ...
    * The Operating System lock screen is shown,

Again, not every platform will have this.  I think it’s OK to have this as one of the examples of the cases where `visible == false`, but it needs to emphasise the fact that the document is not visible, and that’s the reason why `visible == false`.

The PAGE_TASKBAR_PREVIEW case sounds very specific to Windows Vista/7.
It feels wrong to have the web platform reference OS-specific functionality like this (at least minimisation is a concept common across many windowing systems).  Why do we actually want to expose this case?  Is it so that the thumbnail view of the window can show something other than what is shown in the window in its normal view?  Maybe a CSS Media Query would be a better fit for this.

What does the PAGE_PAGE_PREVIEW state correspond to?

--
Cameron McCormack ≝ http://mcc.id.au/

Received on Monday, 2 May 2011 06:38:40 UTC