[css-cascade] Should 'revert' really treat animation origin as author origin?

[Loirooriol]

https://drafts.csswg.org/css-cascade/#default

author origin: Rolls back the cascaded value to the user level, so that the specified value is calculated as if no author-origin rules were specified for this property on this element. For the purpose of revert, this origin includes the Animation origin.

But it's different for revert-layer https://drafts.csswg.org/css-cascade-5/#revert-layer

Note: The animation origin is not collapsed with the author origin for this purpose as it is for revert, and thus effectively forms its own cascade layer.

revert-layer was resolved to respect origins in #6749.

But I wonder if revert really needs to have this strange exception? I have tracked the origin of the text to 9fed7ff and https://lists.w3.org/Archives/Public/www-style/2012Dec/0270.html

Note the text is old, but it's not like revert in @keyframes has much interoperability:

• Blink implemented it in https://chromium-review.googlesource.com/c/chromium/src/+/2132249
• WebKit just treats it as unset, I'm fixing it in https://bugs.webkit.org/show_bug.cgi?id=237073
• Doesn't work in Firefox either

Having to roll back to user origin defeats some optimizations. From the Blink patch:

the existence of the base computed style optimization makes things more complicated, as we can't use this optimization if 'revert' exists in a keyframe. (We don't even match selectors when that optimization is in use, so we wouldn't know what to revert to). In order to fix that, it's necessary to know if an ongoing animation contains a 'revert' or not, and if so disable the optimization in that case.

It's similar in WebKit, when resolving the @keyframes styles, it knows the base styles for the element, but not the styles for each origin. So UA and user declarations need to be recollected if there is a revert.

It doesn't seem a big deal, but given that removing the exception would provide some perf benefits and consistency with revert-layer, it may be worth it?

[andruud]

All for simplifying if it makes sense, but I just wanted to note that the Blink optimization mentioned above would still need to be disabled with this proposal. This is because the value being reverted to may be an em length (for example) which needs to be responsive to a simultaneous font-size animation.

This may make sense to do anyway of course.

We could also classify revert/-layer as special (relevant: #7080 (comment)), and just make them invalid in @keyframes.

[css-meeting-bot]

The CSS Working Group just discussed [css-cascade] Should 'revert' really treat animation origin as author origin?.

The full IRC log of that discussion

<dael> Topic: [css-cascade] Should 'revert' really treat animation origin as author origin?
<dael> github: https://github.com//issues/7083
<dael> oriol: I can explain unless fantasai wants to explain
<dael> faceless: Go ahead
<dael> oriol: The thing is that according to spec when you have revert in keyframes rule, that's animation origin, and revert rolls back. Spec says animation origin is author origin and we roll back to user. Only happens for revert but not revert-layer
<dael> s/faceless/fantasai
<dael> oriol: Having this special behavior for revert surprised me when impl this in webkit where revert didn't work in keyframes
<dael> oriol: Seemed strange
<dael> oriol: Also has performance cost. By time resolving keyframe styles you have base styles of the element. At least WK not tracking which styles are from which declarations. If there's revert I have to recollect all the declarations in order to have proper behavior
<dael> oriol: revert-layer it's just a matter of using base style so no perf hit
<dael> oriol: Not just WK, check in Blink. Mentioned impl this required disabling and optimization.
<dael> oriol: Wondering if could change
<dael> oriol: Anders mentioned blink would still disable optimization due to em units
<dael> oriol: No strong opinion. It surprised me and maybe more consistent to align. But 2 behaviors can give more flexibility to authors
<Rossen_> q?
<dael> Rossen_: Other opinions?
<dael> fantasai: The main thing to think about is if you use revert in animation do you want it to revert to user style sheet? Or revert the rules for the keyframe down to just the authors regular rules
<dael> fantasai: From user PoV that's the question
<dael> fantasai: No strong opinion
<dael> fantasai: I think original thought is revert in author stylesheet removes what author has done. Since animations more likely to be used by author having revert roll back to no author styling made sense at time. I think dbaron proposal for that
<dael> Rossen_: Looking to see if dbaron is here
<dael> oriol: About which one can be more useful, I guess what's spec for revert may be a bit more useful since revert-layer..in most cases you can just remove the declaration. Exception is a fallback in a value
<dael> Rossen_: What would you prefer here? Prefer to try and resolve now?
<dbaron> not here
<dael> Rossen_: Which way would you prefer to take the resolution, oriol? If we need to wait for dbaron I'm sure he can get back to us if her doesn't agree or we wait for dbaron
<dael> oriol: I don't have much of an opinion. Opened for discussion and to know background. I don't have a hurry to resolve
<dael> oriol: Maybe we can wait for dbaron
<dael> Rossen_: If there's no urgency let's continue in GH. I see dbaron so I'm hoping he'll engage on GH

[dbaron]

I don't have a strong opinion on how revert should behave for animations.

I think when I wrote the email in 2012, we'd spent a long time talking about origins as UA-user-author, and those origins do have value in that they reflect the priority of constituencies. Since then, we've moved towards a definition of origins that includes more items and more closely matches how implementations work.

I still think there's some value in aligning with the priority of constituencies. However, I don't see a whole lot of use cases for revert in animations (though maybe I'm missing something), so if doing something different for animations makes things easier to implement, I think that's an entirely reasonable thing to do in order to save the implementation effort for things that are more valuable.

[Loirooriol]

It's not that it's hard to implement, it's that it can have a performance cost. Though andruud said that changing this wouldn't really optimize Blink due to em units. It would benefit WebKit, but WebKit doesn't handle em units correctly in animations. If that's fixed, changing this may not really benefit performance after all.

I'm fine with closing no change, if you think the current spec reflects better the priority of constituencies.

[dbaron]

I guess I'm still curious if anyone has concrete use cases for revert or revert-layer in animations.

[Loirooriol]

Not sure about revert.

revert-layer doesn't generally seem useful since you can just not declare the property in that keyframe. But I guess something like var(--foo, revert-layer) can make sense: if for some reason the variable has not been set, the property will roll back to the non-animated style, instead of becoming IACVT.

[mirisuzanne]

revert-layer doesn't generally seem useful since you can just not declare the property in that keyframe.

I'm not sure that's the same result (at least not in every situation). Leaving a property blank in a keyframe would keep the same value as the previous frame. I think revert-layer would instead use the value defined outside the animation. So it would give you something more similar to currentColor, where you could reference 'current' (pre-animation) values in the animation itself.

[Loirooriol]

You are right, I guess I was thinking a basic animation with only from and to blocks. But using revert-layer between 2 other keyframe blocks that set the same property is not equivalent to omitting it.

[mirisuzanne]

Running an informal Twitter poll. I'm not surprised to see a majority of people unsure about use-cases (many authors only use very simple animations) – but of those with an opinion, several have expressed excitement about having this revert-layer ability inside keyframes, and some frustration only having limited ability to achieve this at the start/end of animations.

This seems to me like both a reasonable/expected behavior for revert-layer in keyframes, and also one that has some utility.

[tabatkins]

Agenda+ for resolution, since the discussion seems to have concluded.

• for revert-layer: suggest closing no-change. There seem to be use-cases from authors that would benefit from the currently-specified revert-layer behavior, and there's not a significant perf impact, per Anders/Oriol.
• for revert: suggest closing no-change (revert reverts the author-levels below the animation as well, stripping back to user origin), since this is what is already specced and implemented. Alternatively, we could sync it with revert-layer for convenience.