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

[graouts]

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]

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

[graouts]

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]

I landed a new tentative WPT test for this in web-platform-tests/wpt#45274 and made it pass in WebKit in WebKit/WebKit#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.