Open graouts opened 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.
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.
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
.
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
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:In WebKit, the obtained values will be (once the mentioned feature bug is fixed)
left: 100px; display: none;
matching theto
keyframe of the forwards-filling animation. In Chrome, the values areleft: 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.