Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen

Looking at https://developer.mozilla.org/en/docs/Web/HTML/Element/iframe

Wouldn't maybe the addition of new attribute to the iframe be the best way?


**************************
autopause
     If present the client can pause any processing related to the 
iframe if the iframe is not currently visible. When unpaused a Page 
Visibility event will be sent to the iframe as if the whole page had 
changed status from invisible to visible.
     For visibility events see 
https://developer.mozilla.org/en-US/docs/Web/Guide/User_experience/Using_the_Page_Visibility_API
**************************

This basically makes it opt in, it changes nothing about the behavior of 
current iframes.
Just an example would be a iframe that can be hidden/unhidden by the 
user clicking a button, and if the iframe has the autopause attribute 
then it's state is effectively paused. Once the iframe is unpaued a Page 
Visibility event is sent and whatever code is running in the frame can 
then react to this and and resume, as it never got a event indicating 
the page was made non-visible a programmer should be able to 
programmatically infer that the iframe was unpaused (it only got the one 
event instead of two).

What type of iframes would benefit from this? Some chats, news feeds, 
log views, anything that "constantly" updates or works in the 
background, but does not need to be updated if not viewable (saves CPU, 
bandwidth, and server resources)

And maybe down the road one could see if a similar autopause can be 
added to the parent page itself (or not). Maybe a "autopause" would make 
sense if added as a attribute to the body (but actually apply to the 
whole document including any scripts declared in the head).

Adding a autopause attribute to a iframe is probably the easiest way to 
add/deal with this.
If nobody ends up using it, it can easily be dropped again too, so there 
is no immediate downside to this that I can currently think of at least.


On 2015-03-31 02:17, Seth Fowler wrote:
> I do want to clarify one other thing: we’re definitely not yet at the point of implementing this in Gecko, especially not in a release version. We think this functionality is important, and modifying the Page Visibility spec is one way to make it accessible to the web. It’s probably even the nicest way to make it accessible to the web, if it’s feasible. But it’s not certain that it’s web compatible or that everyone agrees this is the best way to go; we’re at the starting point of the process here.
>
> I’d be interested to hear any comments that others may have!
>
> Thanks,
> - Seth
>
>> On Mar 30, 2015, at 3:47 PM, Seth Fowler <seth@mozilla.com> wrote:
>>
>> I think we should modify the Page Visibility spec to let UA’s take actual visibility of iframes into account when deciding if an iframe is hidden.
>> ....
>> This design doesn’t do much for iframes which may be doing significant work, though. The most obvious example is HTML5 ads. These ads may be performing significant work - computation, network IO, rendering, etc. Some or all of that work is often unnecessary when the ad is outside the viewport. Having an API that would allow those ads to throttle back their work when they’re not visible could have significant positive effects on performance and battery life.
>>
>> We could get these benefits through a very simple modification of the Page Visibility spec. We should make the visibility of iframes independent of the top-level browsing context, and instead let UA’s take the actual visibility of the iframes into account. If an iframe has been scrolled out of the viewport, has become occluded, or has otherwise been rendered non-visible, we should regard the iframe as hidden and dispatch a visibilitychange event to let the iframe throttle itself.
>> ...
>> - Seth

-- 
Roger Hågensen, Freelancer, http://skuldwyrm.no/

Received on Tuesday, 31 March 2015 06:19:01 UTC