Re: [Page Visibility] Spec Updates

Is "hidden" state issued if the window is only partially obscured (that is, a "keep on top" type window is partially, whether just a few pixels or a whole lot of pixels) on top of the window in question? Or, what if the window is still active but is completely obscured by such another window?

Also, what if a window is active and not obscured, but appears partially off screen (or entirely off screen)?

What if a browser has some "chrome" element (like a menu, dialog, plugin UI, etc) that is displaying partially (or entirely) obscuring the page?

What if a window exists partially or entirely on a second screen, and that second screen is turned off? (I realize that's a stretch, but just wanted to bring it up for completeness/posterity sake).

--------------
In the spirit of this type of functionality, should there be a PAGE_IDLE type of state/event?

--Kyle





From: Jatinder Mann 
Sent: Friday, May 13, 2011 11:14 PM
To: public-web-perf@w3.org 
Subject: RE: [Page Visibility] Spec Updates


Based on feedback from the mailing list and action items from the last conference call, I've made the following updates to the Page Visibility spec, http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility/Overview.html:

 

-          Interface exposed on Document instead of Window

I have updated the Page Visibility properties to be exposed on Document instead of Window to reduce (undeclared) global variable collisions. 

 

-          Feature detection

Using if (document.visible) for feature detection has the downside that the undefined case, which legacy browsers would hit, is equal to the not visible case; meaning legacy browsers will get the behavior defined for the hidden page. An alternative test is to check whether document.visibilityState exists, even if a web developer is only interested in document.visible. Instead, a simpler approach may be to define the boolean as document.hidden. Doing feature detection on document.hidden will ensure that the undefined case is equal to the visible page case; legacy browsers will get the page with the visible behavior. I have updated references to document.visible to document.hidden. Please review this change.

 

I've also updated the example section to use feature detection with document.hidden. 

 

-          PAGE_PRERENDER and PAGE_PREVIEW are optional

Considering these two states may not always make sense for a user agent, they have been defined as optional. E.g., a mobile user agent may not have the concept of a preview. 

 

-          Removed PAGE_OTHER state

If a user agent wants to provide an experimental implementation, they can do so with a prefixed state. The PAGE_OTHER state doesn't provide any additional benefit. As per agreement on the conference call, I have removed this state.

 

-          Constants changed to DOMStrings

Based on feedback, I have changed the constants from unsigned shorts to strings. 

 

-          Fully obscured case.

Based on feedback on the mailing list, determining whether the page is visible when the user agent is fully obscured by another application is difficult. Further, most accessibility tools, like magnifier, require to be full screen. Returning PAGE_HIDDEN in this case will always give the hidden page behavior to accessibility tools. I have added such text to clarify that this scenario may be treated as visible:

"To accommodate accessibility tools that are typically full screen but still show a view of the page, when applicable, document.hidden may return false when the User Agent is not minimized but is fully obscured by other applications."

Please review these changes and provide additional feedback.

 

Thanks,

Jatinder