RE: PageVisibility2, overlap case for iframe

Hi, Marcos:
 Agree that Orientation/Wake has relevancy with PV's visibility semantic. If some case is not cover in Page visibility 1, we can continue discuss and address it in Page visibility 2.
 Let's back to the question related with " potential hidden", appreciate any preference or idea on following option 1 to 3..

Thanks
Pan

-----Original Message-----
From: Marcos Caceres [mailto:w3c@marcosc.com] 
Sent: Thursday, August 28, 2014 2:40 AM
To: public-web-perf; Deng, Pan
Cc: Arvind Jain; Tobin Titus; Mounir Lamouri
Subject: Re: PageVisibility2, overlap case for iframe




On August 27, 2014 at 6:13:27 AM, Deng, Pan (pan.deng@intel.com) wrote:
> Hi
>  
>  
>  
> I scanned the mailing list about Page Visibility 2[1]. I agree on 
> scenarios that inherited from PageVisibility spec [2], like background 
> tab, window minimized etc. While it seems we have not settled down on some browser internal cases for iframes:
>  
>  
>  
> A: hidden if iframe or one of its ancestors is styled "opacity=0" or 
> "visibile=hidden", or "display=none". This case is clear.
>  
> B: hidden if iframe outside of viewport (iframe is in the overflow). 
> This one is also clear and practicable.
>  
> C: hidden if iframe is covered by other positioned elements. For this 
> case, per implementation's view we can check if the iframe is fully 
> covered by other elements' box, if "not", the iframe is indeed visible. The problem is, even if "yes", the iframe is just "potential hidden".
> The scenarios can be very complex, e.g, the foreground element may be 
> text, a round border element, a transparent background box with dot border, or some platform specific controls...
> I'm afraid if we can enumerate all the scenarios, and make sure if it is "indeed hidden"  
> will introduce a lot of overhead, it contradicts the intention of 
> improving performance and power. So I would like to suggest we just 
> sort the "not" cases from all, and marks it as visible, the others should be "potential hidden".
>  
>  
>  
> So, consider to above cases, overall iframe visibility state should be:
>  
> visible when A=visible and B=visible, and C=visible.
>  
> hidden when A=hidden or B=hidden.
>  
> The problem is how we define visibility state of A=visible and 
> B=visible and C="potential hidden".
>  
> Option 1: Keep current "visible" and "hidden" semantic to avoid 
> introduce any new state, while only cover case A and B, forget C.
>  
> Option 2: Cover case C, while introduce new state "potential hidden" 
> (or potential visible)
>  
> Option 3: Cover case C, do NOT introduced "potential hidden", just report "visible"  
> for "potential hidden" case.
>  
> I don't have strong preference, your idea?


I just want to throw some more implementer weight behind clarifying this in the spec. Both the Orientation Lock API and the Wake Lock API are heavily reliant on "visibility" as per the Page Visibility spec, but the page visibility spec doesn't give us a normative definition of what visible means. 

This is going to lead to interoperability problems across UAs. What is the plan to address this?


> [1] 
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility2/Over

> view.html
>  
> [2] http://www.w3.org/TR/page-visibility/

>  
>

Received on Monday, 1 September 2014 09:12:13 UTC