Re: Animation frame task

On Fri, Aug 22, 2014 at 8:07 AM, James Robinson <> wrote:
> HTML defines the event loop and it defines (as much as anything does) when
> the 'update the rendering' step happens, which is I think when all of this
> should be tied to. Specifically I think we should extend Step 8 of the
> processing model:
> 8.) Update the rendering: If this event loop is a browsing context event
> loop (as opposed to a worker event loop), then, if necessary, update the
> rendering or user interface of anyDocument or browsing context to reflect
> the current state.
> To say something like:
> To update the rendering, run these steps:
> 1.) Run tasks in the bag-of-stuff-to-run-before RAF in some order (probably
> FIFO).  This includes the set of things Elliot mentioned (scroll updates,
> media queries, etc etc) and anything else we want to put in other than the
> requestAnimationFrame events themselves
> 2.) Run the 'Sample all animations' task:
> 3.) Render the document to reflect the current state
> I think it's important that rAF callbacks be the last script thing that runs
> here so the author has a chance to get everything ship-shape before
> rendering actually happens, else you get flashes and inconsistencies like
> the ones in the test case Elliot demonstrated.  I'm not sure if we need the
> step in (1) to be hookable by other specs or not but it might be useful.

Yes we should make that extensible.

> If we want to define that to be FIFO then we have to strictly define when
> items in that queue are added to the queue, which for things like media
> queries and other CSS/layout-driven tasks might be hard.

This will end up being required I think. The more we make this
extensible, the more observable and painful it will get for developers
if we do not fix this.

I filed on HTML
pointing to your email as a start towards fixing this.


Received on Friday, 22 August 2014 09:11:09 UTC