RE: [PageVisibility] What should the visibility api return in display:none iframes?

Considering that prior to this spec visibility information of the Page (top level document) or IFrame were not available to web developers, supporting only Page visibility and not IFrame visibility in this spec will not make things strictly worse for web developers.

That being said, I think this spec has the option of either defining IFrame visibility to mirror the visibility of the top level document or to reflect its true visibility with respect to styling applied to it and its on screen position. I can only think of two cases where the more detailed IFrame visibility seems interesting:


(A)   Cross-origin IFrame hidden via styling. An ad-blocker extension, could for example, turn all cross-origin IFrames to display:none to block ads. In this case, the cross-origin IFrame cannot query its parent document to see its styling - a same-origin IFrame would not suffer from this restriction. With detailed IFrame visibility, it may be aware of this styling and may throttle its processing work.



(B)   Cross-origin IFrame is no longer in the viewport. A cross-origin IFrame may no longer be visible to a user, even when in the active page, as it may have been scrolled out of the view port. The IFrame may want to stop processing work. This could be the case of an ad that is no longer visible and the ad owner may want to pause the advertisement.


The first case feels like an edge case to me, though, there does feel to be some value in the second case. Currently, the spec makes the simplifying assumption that all portions of the page in the active tab are visible. I think we need to discuss if the value of supporting these cases outweighs the cost of complicating this otherwise simple spec. Please do mention other cases that I may have missed.

As for element visibility, considering an element's formatting and position in the view port can always be calculated, the ability to determine element visibility is available today. Even if we do consider such an API, I think it's out of scope for this spec, which is more centered around the document. There was talk of including element visibility as an optional parameter for the requestAnimationFrame API, but it hasn't been spec'd out yet.

Thanks,
Jatinder


From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Shishir Agrawal
Sent: Monday, October 10, 2011 10:27 AM
To: Jonas Sicking
Cc: Jatinder Mann; Anne van Kesteren; Arvind Jain; Boris Zbarsky; public-web-perf@w3.org
Subject: Re: [PageVisibility] What should the visibility api return in display:none iframes?

We started discussing the spec as a way for pages to figure out how they were embedded in the browser: foreground tab, background tab etc. I dont think we should implement the display:none case because,

- Keeping the spec simple - ensures that the spec is implemented consistently. The more complicated we make the spec, we may see vendors diverge from it.
- The discussion to include some cases - such as display:none and not others like visibility:hidden, or pages hidden by window seem a bit arbitrary to me. Like I mentioned this was also not the intended use of the initial spec (ofcourse that can change).

Thanks
Shishir


On Fri, Oct 7, 2011 at 2:13 PM, Jonas Sicking <jonas@sicking.cc<mailto:jonas@sicking.cc>> wrote:
On Fri, Oct 7, 2011 at 11:26 AM, Shishir Agrawal <shishir@chromium.org<mailto:shishir@chromium.org>> wrote:
> If we want to include display none, why not consider other visibility cases
> - All of which would probably benefit web developers. I think the idea was
> to keep the page visibility consistent and simple.
Simpler for who? The web developer or the person implementing the spec?

So far no-one has been able to argue why this is better for the web
developer. As far as I can see it's strictly worse for them.

I'm certainly open to adding other visibility cases. Anne brought up
visibility:hidden which I would be ok with, though as I explained
there are arguments against it.

/ Jonas