Re: [cssom-view][css3-animations] Sync events with requestAnimationFrame

On Tuesday 2014-12-09 11:00 +0100, Simon Pieters wrote:
> HTML is invoking a hook that does not yet exist.
> 
> [[
> For each fully active Document in docs, run CSS animations and send
> events for that Document, passing in now as the timestamp.
> [CSSANIMATIONS]
> ]]

To be honest, I'm somewhat skeptical that the order and manner in
which the HTML spec invokes those hooks is correct (mainly because
it has very little resemblance to what we actually do in our
implementation), but figuring out what I think should be there
instead is a rather large task.

My concerns about
https://html.spec.whatwg.org/multipage/webappapis.html#processing-model-9
are largely related to:

(1) Some of the steps in the "Update the rendering" list also need
    to be done when certain things are flushed (e.g., evaluating
    media query changes), in addition to during a refresh tick
    (items 8.4 - 8.10).  (Maybe this is specified elsewhere,
    though?)

(2) The relative ordering needs to be handled more carefully.  In
    particular, the refresh tick (8.4 - 8.10) has to:
     a. do things that might update specified style
     b. run event handlers
     c. flush style and layout in order to render
    Items in (b) might flush style and layout from script; this
    means that in general the things in (a) should all be done
    before the event handlers in (b), so that they're seeing current
    style data *if they happen to flush*.  Items in (b) are also
    allowed to update current style data; this can lead to
    interleaving of setting style and flushing it, but that's
    unavoidable, and putting (b) before (a) doesn't improve this.
    In other words, the animations should all tick their notion of
    current style first, so that event handlers resulting from the
    refresh tick get current style data rather than style data
    resulting from the previous refresh tick.

    If animations are the only thing that can do both (a) and (b)
    then it's possible for animations to have a single hook.  (In
    our implementation I think that might be the case, since we
    don't update media queries as part of the refresh timer
    handling...  although perhaps something related to scrolling
    means that isn't the case anymore.)

    This definitely requires that the "run CSS animations and send
    events" be before the 3 steps that currently precede it ("run
    the resize steps", "run the scroll steps", and "evaluate media
    queries and report changes"), since the hooks in those steps
    appear to only fire events and not post style changes.  But I
    suspect it requires bigger changes to the spec's model as well.
 
(3) Also, the work should happen for both CSS Animations and CSS
    Transitions.  (This one is minor.)

As I said, though, figuring out how I'd want the spec to address (1)
and (2) is a rather large task; it requires carefully looking at the
other things that interact with these things.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)