Skip to content

[css-backgrounds-3] Clarification on animation additive composite behavior for box-shadow #4330

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
stephenmcgruer opened this issue Sep 18, 2019 · 4 comments · Fixed by #4374

Comments

@stephenmcgruer
Copy link
Contributor

stephenmcgruer commented Sep 18, 2019

Currently the spec for box-shadow (https://drafts.csswg.org/css-backgrounds/#box-shadow) does not appear (to my quick reading) to give any instructions for additive composition (https://drafts.csswg.org/web-animations-1/#effect-composition) when animating.

In the absence of a behavior for addition, the fallback is to use replace (https://drafts.csswg.org/css-values-4/#combining-values).

Firefox instead appears to implement box-shadow interpolation as list concatenation, as shown by https://output.jsbin.com/pikiguv. Chrome appears to do component-wise addition. Which, if either, is correct?

EDIT: Note, you will need composited modes enabled in the browsers if you test them. For Chrome, that's chrome://flags, set "experimental-web-platform-features" to enabled. For Firefox, you can test using Firefox Nightly (has it enabled by default).

@stephenmcgruer
Copy link
Contributor Author

cc @birtles

@stephenmcgruer
Copy link
Contributor Author

For the record, generally with list-y things, add is spec'd as list concatenation and accumulate is spec'd as component-wise addition.

Also, it's very possible this is spec'd for box-shadow and I overlooked it, so please lmk if so.

@flackr
Copy link
Contributor

flackr commented Sep 18, 2019

From a developer ergonomics point of view, I think concatenation makes more sense. It's as if you are adding another shadow. As for what is correct - it is animatable as a shadow list. The definition for how to animate a shadow list moved to web-animations-1 from css-transitions-1 https://www.w3.org/TR/web-animations-1/#animating-shadow-lists which suggests it should be component-wise.

(aside: is there an easier way to track down these things rather than digging through git histories to find where the definitions moved? I.e. where's the standard place to look for a type's interpolation / addition / accumulation behavior?)

@stephenmcgruer
Copy link
Contributor Author

Dammit, I though we killed all the overrides in the animations specs -_-. I didn't realize they had jumped to web-animations-1 from css-transitions-1 :(.

I would quite like to kill https://www.w3.org/TR/web-animations-1/#animation-types; what is stopping us from moving the information into the relevant specs?

text-shadow has the same interop discrepancy btw, and I don't think it made it to web-animations-1

stephenmcgruer added a commit to stephenmcgruer/csswg-drafts that referenced this issue Sep 26, 2019
To align with other list-list properties, box-shadow
addition/accumulation is changed to be defined as concatenation for
addition (previously component-wise addition) and component-wise
addition for accumulation (previously unspec'd).

Fixes w3c#4330
stephenmcgruer added a commit to stephenmcgruer/csswg-drafts that referenced this issue Sep 26, 2019
birtles pushed a commit that referenced this issue Oct 3, 2019
To align with other list-list properties, box-shadow
addition/accumulation is changed to be defined as concatenation for
addition (previously component-wise addition) and component-wise
addition for accumulation (previously unspec'd).

Fixes #4330
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants