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/Overview.html  
>  
> [2] http://www.w3.org/TR/page-visibility/
>  
>

Received on Wednesday, 27 August 2014 18:40:45 UTC