-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove zoom-with-sign-function.html from interop-2025 #939
Remove zoom-with-sign-function.html from interop-2025 #939
Comments
Seems ok to me |
Thanks! I'll write a PR to remove the test from the interop set. |
Folks from Chromium haven't replied yet it seems |
Oh right, I misremembered that they had replied. @chrishtr would you mind signing off on this? (Basically the same tests/reasoning as #937 as noted above; it's a test that was included due to having zoom in the name, but is really testing an edge-casey parser behavior that's unrelated to zoom in particular. The tests themselves are essentially identical to the ones I spun out in #937.) Thanks! |
LGTM! |
Test List
https://wpt.fyi/results/css/css-viewport/zoom/zoom-with-sign-function.html
Rationale
This test is currently included in interop-2025 "webcompat" focus area as part of support for the "zoom" property (proposed in #825 )
However, this test (zoom-with-sign-function) is actually testing a largely-unrelated thing, and just happens to be using the
zoom
property to do it. It's a test for whethersign(1em - 1px)
parses and computes as-expected, which as discussed in #867 (comment) has some subtlety (and was proposed as part of a focus area over there and was rejected). Currently, Firefox rejects this syntax and fails this WPT test as a result.In my opinion, it doesn't make sense to consider
zoom
interoperability as depending on howcalc(sign(1em - 1px)...)
behaves, so I propose we remove this test from interop-2025.(Note that we do have a different WPT that's included in interop-2025 that also has test coverage for various
zoom
parsing scenarios, and in #937 I've separately proposed splitting out similar bits from that test, but leaving behind some simplercalc(...sign(...))
expressions that do work interoperably.)The text was updated successfully, but these errors were encountered: