Re: [csswg-drafts] [css-display] Why is display listed as not animatable instead of animation type: discrete? (#6429)

> I think I'd like to confirm with the other implementers what is the easiest set of restrictions to implement, whether it's easier to be more targetted about it or to be more broad about it.

> So when I was experimenting with animating content it seemed like Firefox didn't stop animating the pseudo-element even when content was none. This got me wondering whether we could only remove animations if the base computed display style AND the computed display style is none. This might I think fix the circularity issues and allow the feature to work the simple way that a developer would expect.

I have implemented both display:none->display:revert and flackr's idea here of not canceling the animation when the animation sets the style to display:none. Unless there are edge cases I'm not thinking of, both were similar in difficulty to implement. I don't have a preference yet of which we should go with, but I defer to flackr's judgement.

To implement display:none->display:revert, I modified the style resolution code in parts where it knows that the style is being applied for an animation to change display:none to display:revert. It required additional changes in another spot to handle this case with variables:
```css
@keyframes hello {
  0% { --display-value: none; }
  100% { --display-value: none; }
}
#target {
  display: var(--display-value, block);
}
#target.animation {
  animation-name: hello;
  animation-duration: 1s;
}
```

To implement not canceling the animation when an animation sets display:none, I used similar spots in the style resolution code but set a flag on the element when the animation sets display:none, so that the element knows that it shouldn't cancel the animation right after it recalcs its own style.

## use cases

Not canceling the animation provides the ability to animate to display:none and back with keyframes during an animation and actually make the element disappear, but I don't know if that's a use case that we need to support. Here is an example of what that would look like:
```css
@keyframes {
  0% { display: block; }
  20% { display: none; }
  80% { display: none; }
  100% { display: block; }
}
```

> Display is interpolated like visibility, i.e. it will prefer the non-none value.

Due to this `visibility`-like behavior, **none of the following use cases will be affected by the display:none->display:revert or don't cancel the animation behavior** because there has to be a full interpolation step to and from display:none. All of these examples will be display:block for the entire duration of the animation regardless of which implementation option we choose.

```css
@keyframes {
  0% { display: block; }
  100% { display: none; }
}
```
```css
@keyframes {
  0% { display: none; }
  100% { display: block; }
}
```
```css
#target {
  display: block;
  transition: display 1s;
}
#target.animated { display: none; }
```
```css
#target {
  display: none;
  transition: display 1s;
}
#target.animated { display: block; }
```

-- 
GitHub Notification of comment by josepharhar
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6429#issuecomment-1500616791 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 7 April 2023 20:29:27 UTC