Refactor computed style code for transition-property and the transition shorthand
Created attachment 448366 [details] Patch
Comment on attachment 448366 [details] Patch looks like some rebasing is needed
Created attachment 448382 [details] Patch for landing
Comment on attachment 448382 [details] Patch for landing View in context: https://bugs.webkit.org/attachment.cgi?id=448382&action=review > LayoutTests/imported/w3c/web-platform-tests/css/css-pseudo/first-letter-allowed-properties-expected.txt:35 > -FAIL transition should not be applied to first-letter pseudo elements. assert_equals: expected "all 0s ease 0s" but got "transform 1s ease 0s" > +FAIL transition should not be applied to first-letter pseudo elements. assert_equals: expected "" but got "transform 1s ease 0s" Does this change make sense? Why did the *expected* value change?
(In reply to Darin Adler from comment #4) > Comment on attachment 448382 [details] > Patch for landing > > View in context: > https://bugs.webkit.org/attachment.cgi?id=448382&action=review > > > LayoutTests/imported/w3c/web-platform-tests/css/css-pseudo/first-letter-allowed-properties-expected.txt:35 > > -FAIL transition should not be applied to first-letter pseudo elements. assert_equals: expected "all 0s ease 0s" but got "transform 1s ease 0s" > > +FAIL transition should not be applied to first-letter pseudo elements. assert_equals: expected "" but got "transform 1s ease 0s" > > Does this change make sense? Why did the *expected* value change? I'll double check, but I think the expected string is created dynamically by getting the computed style of a non-pseudo element, which would explain this behavior.
(In reply to Antoine Quint from comment #5) > (In reply to Darin Adler from comment #4) > > Comment on attachment 448382 [details] > > Patch for landing > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=448382&action=review > > > > > LayoutTests/imported/w3c/web-platform-tests/css/css-pseudo/first-letter-allowed-properties-expected.txt:35 > > > -FAIL transition should not be applied to first-letter pseudo elements. assert_equals: expected "all 0s ease 0s" but got "transform 1s ease 0s" > > > +FAIL transition should not be applied to first-letter pseudo elements. assert_equals: expected "" but got "transform 1s ease 0s" > > > > Does this change make sense? Why did the *expected* value change? > > I'll double check, but I think the expected string is created dynamically by > getting the computed style of a non-pseudo element, which would explain this > behavior. Precisely: const target = document.querySelector("#target"); var defaultComputedStyle = getComputedStyle(target); I'll take a look at making this test pass as well.
Committed r287669 (245766@main): <https://commits.webkit.org/245766@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 448382 [details].
<rdar://problem/87176839>
(In reply to Antoine Quint from comment #6) > (In reply to Antoine Quint from comment #5) > > (In reply to Darin Adler from comment #4) > > > Comment on attachment 448382 [details] > > > Patch for landing > > > > > > View in context: > > > https://bugs.webkit.org/attachment.cgi?id=448382&action=review > > > > > > > LayoutTests/imported/w3c/web-platform-tests/css/css-pseudo/first-letter-allowed-properties-expected.txt:35 > > > > -FAIL transition should not be applied to first-letter pseudo elements. assert_equals: expected "all 0s ease 0s" but got "transform 1s ease 0s" > > > > +FAIL transition should not be applied to first-letter pseudo elements. assert_equals: expected "" but got "transform 1s ease 0s" > > > > > > Does this change make sense? Why did the *expected* value change? > > > > I'll double check, but I think the expected string is created dynamically by > > getting the computed style of a non-pseudo element, which would explain this > > behavior. > > Precisely: > > const target = document.querySelector("#target"); > var defaultComputedStyle = getComputedStyle(target); > > I'll take a look at making this test pass as well. So this actually caused a regression in iOS 15.4 (bug 237920), all because I wasn't thorough enough in my analysis of why this test's failing output changed. I added some more explicit WPT coverage so we don't end up in this kind of situation again.