Re: agenda+ RequestNimationFrame and iframe/display:none

On Wed, Aug 7, 2013 at 6:37 AM, Philippe Le Hegaret <plh@w3.org> wrote:

> On Wed, 2013-08-07 at 00:50 +0000, Jatinder Mann wrote:
> > Working Group Conference Call (1-2PM EST/10-11AM PST)
> >
> >
> >
> > 1.    Discussnew specifications
> >
> agenda+ RequestAnimationFrame
>
> While talking with the Director to test the ground regarding the
> objection on RequestAnimationFrame, he came up with a question:
>
> Right now, the specification indicates:
> [[
> Whenever a Document's hidden attribute is false and the animation frame
> request callback list is not empty, the user agent MUST regularly queue
> a task that samples all animations for that Document's top-level
> browsing context.
> ]]
>
> Because we're tied to Page Visibility, and the definition of Page
> Visibility is limited, there is no room for the browser to be smart,
> e.g. not ticking on display:none on iframes.
>

That wouldn't be smart, it would just break pages.  Consider:

example.com/main.html:
<!DOCTYPE html>
<iframe src="script_frame.html"></iframe>
<div id="target">.....</div>

example.com/script_frame.html:
<!DOCTYPE html>
<script>
window.requestAnimationFrame(function() {
  window.top.document.querySelector("#target").style = ...;
}
</script>


In this case, the requestAnimationFrame call is made on the context
associated with the iframe, but it's animating an element in the parent
frame.  The styling of the iframe are irrelevant for the behavior of the
animation itself.

This method of script loading is not all that uncommon - it's how gmail
works.


>
> What is the rational for not letting the browser be smart here and give
> it room not to tick? [1] doesn't seem enough to explain the current
> pushback.


> Ie something along:
> [[
> Whenever a Document's hidden attribute is false and the animation frame
> request callback list is not empty, the user agent MUST regularly queue
> a task that samples all animations for that Document's top-level
> browsing context unless the user agent is able to determine that the
> impacted elements are hidden.
> ]]
>

There's no way for a browser to "determine that the impacted elements are
hidden", or even for a browser to determine what the impacted elements are
in the current spec.  If in a V2 version of the spec we provide a way for
the author to provide more information about what element(s) the animations
will impact we could add a behavior like this, but in the current API
there's no way for a browser to do something like this.

- James


> Regards,
>
> Philippe
> [1]
> http://lists.w3.org/Archives/Public/public-web-perf/2013Apr/0033.html
>
>
>
>

Received on Wednesday, 7 August 2013 23:39:45 UTC