w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.46k stars 657 forks source link

[css-display-4] [css-animations-2] clarify and test how `display` animations involving `none` interact with pseudo-elements #10111

Open graouts opened 6 months ago

graouts commented 6 months ago

Chrome has added support for the display property and work to add similar support in WebKit is ongoing (bug 267762). As part of this work, I noticed the Blink test fast/css-generated-content/pseudo-animation-display.html was yielding different results in Chrome and WebKit and it was not obvious to me which of the two engines, if any, is correct. Here is the relevant part of this test:

#target:after {
    display: block;
    content: "";
    background-color: blue;    
}

#target.animated:after {
    animation: anim 1ms forwards;
}

@keyframes anim {
    from { left: 0px; display: block; }
    to { left: 100px; display: none; }
}
const target = document.getElementById('target');
target.addEventListener('animationend', () => {
    const style = getComputedStyle(target, ':after');
    test(style, 'left', '100px');
    test(style, 'display', 'block');
});
target.classList.add('animated');

In WebKit, the obtained values will be (once the mentioned feature bug is fixed) left: 100px; display: none; matching the to keyframe of the forwards-filling animation. In Chrome, the values are left: auto; display: block;, indicating that the animation is not applied.

It's not immediately obvious to me what the right behavior is here, and additionally I don't think WPT has test coverage that matches this.

graouts commented 6 months ago

Cc @josepharhar who seems to have done the bulk of the work for display animation in Chrome and @flackr who has reviewed it.

graouts commented 6 months ago

If I modify the test to apply to a non-pseudo element, Chrome and WebKit agree on the results and the to animation keyframe values are reflected in the computed style after the animation completes. I think the question when it comes to the ::after pseudo-element in this case is whether display: none has any specific bearing.

graouts commented 6 months ago

I landed a new tentative WPT test for this in https://github.com/web-platform-tests/wpt/pull/45274 and made it pass in WebKit in https://github.com/WebKit/WebKit/pull/26312. Happy to revisit this if this is warranted, but I think ::after and ::before should not cancel display animations if the computed value is none.

josepharhar commented 5 months ago

Sorry for the slow reply

::after and ::before should not cancel display animations if the computed value is none.

This sounds reasonable to me! I filed an issue here: https://issues.chromium.org/issues/336842915