[css-transitions-1] Define before/after-change style in terms of base

[andruud]

• Introduce "base style".
• Define before/after-change style in terms of that base style
  (at two different points in time).
• There should be no need for the "completed transition" set anymore,
  since the before/after-change styles on a child are blind to any
  effects from transitions/animations happening on the parent.

See also #6398.

[andruud]

This needs a resolution, but proposing an edit ahead of time so we know exactly what to resolve on.

[dbaron]

I think this looks good to me (although it has some compatibility risks... though perhaps low given that current implementations don't agree very much), but I think this either needs working group consensus or at least approval from the other implementors of transitions, in #6398.

It's possible the list could be further simplified at this point, but it will be easier to tell once this lands.

[birtles]

I think this represents a change to case 11 from https://bug1192592.bmoattachments.org/attachment.cgi?id=8843824. That is, I believe with this proposal it would be possible to trigger a transition while an animation is running. Maybe that's ok but it does seem a bit risky in terms of compatibility, since browsers appear to agree on that at the moment.

Also, I'm really rusty on how all this fits together but I believe in Gecko at least SMIL animated styles are written to an override stylesheet separate to the animations level of the cascade whereas this PR seems to assume they are written to the animations level of the cascade.

[andruud]

case 11

I think you're right. Although while the animation is running, the transition would add no effect value to the cascade. https://drafts.csswg.org/css-transitions-1/#application. But it would be observable via events, and when the animation ends sooner than the transition.

• You'd think that it's uncommon for authors to specify a transition and an animation on the same property. If you like I can add a (Chrome) use-counter to see how often a would-be transition is "blocked" by a running animation, or
• We could explicitly specify in https://drafts.csswg.org/css-transitions-1/#starting that a transition should not start if there's currently an animation on the same property. I don't think that behavior must arise from the current definition of before/after-change style?

SMIL, cascade

Oh, that's unfortunate. Thanks for pointing that out. I'll have to investigate more to know what makes sense there.

[birtles]

• You'd think that it's uncommon for authors to specify a transition and an animation on the same property. If you like I can add a (Chrome) use-counter to see how often a would-be transition is "blocked" by a running animation, or

• We could explicitly specify in https://drafts.csswg.org/css-transitions-1/#starting that a transition should not start if there's currently an animation on the same property. I don't think that behavior must arise from the current definition of before/after-change style?

Thanks. I'm not sure which is preferable. If there's time, adding the use counter would be safest.

If we decide to change this behavior, I guess it would be little odd that transition events are fired even when there's no visual change. Maybe it's ok though.

[andruud]

@birtles I have now added the use-counter to Chrome to investigate. I'll report back in a few months when good data comes in.

Meanwhile, could you have a look at this as well @smfr?

[birtles]

@birtles I have now added the use-counter to Chrome to investigate. I'll report back in a few months when good data comes in.

Thank you!

[mirisuzanne]

@andruud any updates on this?

[andruud]

Yes, but not the update I wanted. The use-counter is at almost 4%, which is way higher than expected. I've been waiting for sample pages to come in so I could check if there's any typical usage patterns we could use to argue that the change doesn't matter, but at 4% it might be futile to find the "typical" usage patterns anyway.

So as it stands, the use-counter did not help in making a confident decision here, unfortunately.

@birtles In light of this, do you think we should do the following?

We could explicitly specify in https://drafts.csswg.org/css-transitions-1/#starting that a transition should not start if there's currently an animation on the same property. I don't think that behavior must arise from the current definition of before/after-change style?

[birtles]

@birtles In light of this, do you think we should do the following?

We could explicitly specify in https://drafts.csswg.org/css-transitions-1/#starting that a transition should not start if there's currently an animation on the same property. I don't think that behavior must arise from the current definition of before/after-change style?

I think so. Transition events are quite important to a lot of apps -- often various state changes are keyed off getting a transitionend event. I think any change to the circumstances under which transition events are dispatched is risky and we should try to match the current (interoperable) behavior there.

(Anecdotally, many many years ago when working on Firefox OS, a recurring cause for apps breaking was that they didn't receive expected transitionend events which is what motivated specifying the transitioncancel event.)

[andruud]

OK, thanks @birtles. I'll update this PR with new proposed text as soon as I can.

[flackr]

Sounds good to me to make transitions not start if there is an animation on that property. I think you should look for animations in the after-change style so that we avoid starting a transition in the case in #8701.

As an extreme use case, consider a page which makes use of both transitions and animations to move an element around, e.g.

<style>
#target {
  transition: transform 1s;
}
</style>
<script>
moveTo(transform) {
  let animation = target.animate([{transform}], {duration: 1000, fill: 'forwards'});
  animation.finished.then(() => {
    // Changes the base style to match the animated position.
    animation.commitStyles();
    animation.cancel();
  });
}
</script>

The call to commitStyles should not start a transition (this would cause the element to move back to its old location and slide back to the target). I think this would be fine right now because the animation is still technically active, however we should also make sure that with #5394 you can omit the fill and have the animation technically not active in the final frame, i.e.

bounceTo(transform) {
  let animation = target.animate([{transform}], 1000);
  animation.finished.then(() => {
    // Changes the base style to match the animated position.
    animation.commitStyles();
  });
}

In this case the animation is technically no longer active but was previously - so perhaps this is just justification to consider animations in the before or after change style?