[css-backgrounds-4] Fixed and added definitions for box-shadow-offset: none #8605
Conversation
There was a problem hiding this comment.
box-shadow should also change to "Computed value: see individual properties".
BTW, "Animation type" should also be "see individual properties", and the animation logic should go to the right property, but I guess that depends on #8592.
There was a problem hiding this comment.
I've changed the computed value and removed the now incorrect note for "Animatable" about "treating none as a zero-item list".
I kept the animation logic at the shorthand for now and will fix it in the patch for #8592.
I also kept "Animatable" for now and replace it in another patch by "Animation type" as it's unrelated to this one.
css-backgrounds-4/Overview.bs
Outdated
| Animatable: by computed value, | ||
| treating ''box-shadow-offset/none'' as a zero-item list | ||
| and appending blank shadows (''transparent 0 0 0 0'') | ||
| appending blank shadows (''transparent 0 0 0 0'') |
There was a problem hiding this comment.
Just dropping "treating none as a zero-item list" would change the behavior.
I think that box-shadow-offset should treat none as 0 0 when interpolated with non-none values.
There was a problem hiding this comment.
The idea was to align it with animation-name, i.e. a value of none cancels out this one shadow within the list.
And I think it is better to treat none as-is, meaning the interpolation between none and non-none values is discrete and the shadow appears or disappears.
Sebastian
There was a problem hiding this comment.
Well this would break https://software.hixie.ch/utilities/js/live-dom-viewer/saved/11442 which works with interoperability, so you need CSSWG resolution to change it.
css-backgrounds-4/Overview.bs
Outdated
| Animatable: by computed value, | ||
| treating ''box-shadow-offset/none'' as a zero-item list | ||
| and appending blank shadows (''transparent 0 0 0 0'') | ||
| with a corresponding ''box-shadow-position/inset'' keyword as needed | ||
| to match the longer list | ||
| if the shorter list is otherwise compatible with the longer one | ||
| letting ''box-shadow-offset/none'' create a blank shadow | ||
| (''transparent 0 0 0 0'') when interpolated with non-'none' values | ||
| and appending blank shadows with a corresponding | ||
| ''box-shadow-position/inset'' keyword as needed to match the longer list | ||
| if the shorter list is otherwise compatible with the longer one |
There was a problem hiding this comment.
I don't think this works.
Let's say we interpolate from box-shadow-offset: none; box-shadow-color: #f00 to box-shadow-offset: 10px 10px; box-shadow-color: #f00.
box-shadow-offset interpolates none as 0 0, so at linear 50% we have 5px 5px. But what about box-shadow-color? Its computed value was always #f00 (none was only changing the used value into transparent), so we get #f00, but current browsers say rgba(255, 0, 0, 0.5).
So I guess that either:
box-shadow-offset: noneshould affect the computed values of other properties (even though coordinated value lists were only supposed to affect each other at used value time I believe).- Interpolation with
box-shadow-offset: noneshould not just treat it as0 0but somehow affect the used value of other properties at used value time. - We get rid of this magical behavior, as you initially wanted.
2f413e4 to
a00eeb3
Compare
|
Since we split borders and box decorations out into CSS Borders 4, I'll close this PR and set up a new one to avoid rebasing issues. Sebastian |
|
For reference, the new PR is #9096. |
I've added the definition for the
nonevalue ofbox-shadow-offsetand corrected the computed value of that property to account for thenonevalue now being part of the shadow list.This is meant to fix #8567.
Sebastian