This happens on Safari 17.4 beta and Technology Preview. https://jsbin.com/lilakiqene/edit?html,css,js,output The :empty selector with animation style continues to be applied even after adding child elements.
Thank you for the report! Could you please clarify if this a new issue Safari 17.4 beta and Technology Preview that does NOT affect shipping Safari?
I confirmed that this issue does NOT happen in Safari 17.3.
<rdar://problem/122838142>
Here is what I am seeing when I click on the "Add Child" button: Chrome and Firefox: spinning blue square at the bottom becomes a static white square with "Child" label Safari 17.4 and STP 188: spinning blue square at the bottom remains blue and keeps spinning but also as a "Child" label Safari 17.3.1: spinning blue square at the bottom is unchanged Is the change between Safari 17.3.1 and Safari 17.4 described above what you are seeing as well? In either case, I believe we are not doing the right thing.
My confirmation was incorrect. There seems to be something wrong with Safari 17.3.1 as well.
I believe this is unrelated to animations and simply a style invalidation issue since the background-color remains stuck on blue. Querying the computed style from the Web Inspector addresses the issue.
Created attachment 470209 [details] Test Actually I cannot make it happen without an `animation` property set on the element, so it does appear like animation is related to this issue.
Comment on attachment 470209 [details] Test <!DOCTYPE html> <html> <head> <title>WebKit Bug 269051</title> <style> .parent { width: 100px; height: 100px; background-color: green; } .parent:empty { background-color: red; animation: animation 1s; } @keyframes animation { } </style> </head> <body> <div class="parent"></div> <script> setTimeout(() => document.querySelector('.parent').appendChild(document.createElement('div')), 1000); </script> </body> </html>
Created attachment 470210 [details] Test
As the document is initially parsed, Document::finishedParsing() is called and eventually Element::setStyleAffectedByEmpty() is called on the <div> under Style::TreeResolver::styleForStyleable(). The call to setStyleAffectedByEmpty() will set the StyleAffectedByEmpty flag which will allow the static function checkForEmptyStyleChange() to not return early when style changes occur on that <div> element later. In the case where there is no `animation` style on that element, an additional call to Style::TreeResolver::resolveComposedTree() occurs due to a page rendering update and the <div> element is re-resolved. This time, when the <div> is visited, determineResolutionType() returns AnimationOnly and resetStyleRelations() is called, removing the StyleAffectedByEmpty flag. This explains the change in behavior with or without the `animation` style. I'm not sure how to deal with this yet. Should we avoid calling resetStyleRelations() or should we have another call to setStyleAffectedByEmpty() afterwards?
Pull request: https://github.com/WebKit/WebKit/pull/25583
Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/44984
Committed 275832@main (319ecb9c28e3): <https://commits.webkit.org/275832@main> Reviewed commits have been landed. Closing PR #25583 and removing active labels.
*** Bug 270885 has been marked as a duplicate of this bug. ***