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)