-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
[css-values] Reftest for percentage root font size and rem units #18941
[css-values] Reftest for percentage root font size and rem units #18941
Conversation
<meta name="assert" content="When :root font-size is 20%, a 31.25rem length must be 100px, if the browser default for :root font-size is 16px."> | ||
<style> | ||
:root { | ||
font-size: 20%; /* default is 16px in all desktop browsers */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this be set to a fixed value in px, like 3.2px or maybe some other very small value that makes the other numbers nice and round? This way the test doesn't depend on the default font size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Blink/WebKit bug is specifically about percentages, no?
That said, I'd rather we go for for 25% if we can (because then we get a nice round 4px and avoid any potential subpixel rendering differences).
Also we already assume 16px
as default all over the place. We could write a new reference (maybe a 8rem square to keep everything integral) for this if we have any interest in changing that, but I don't think we do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Blink issue is not related to percentages. It's generally about minimum font-size being applied to font-size before it's used to resolve em and rem units.
I'd pick a really small font-size (< 1px ?) to make sure any minimum font-size will affect the issue. In danger of introducing too much churn here, this could have been a testharness.js test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lilles In my tests, I can always reproduce the bug if I use low percentage but not with small px values. But Trevor Burnham's (https://bugs.chromium.org/p/chromium/issues/detail?id=308862#c21) demo does highlight that it is not the only case. https://codepen.io/TrevorBurnham/pen/VXqoEW
I'm not sure why.
I don't know what a testharness.js test is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gsnedders I'll change it to 25%
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See https://web-platform-tests.org/writing-tests/testharness.html for testharness.js
tests. I think writing a test based on Trevor Burnham's asserting that window.getComputedStyle(x).fontSize
is the same for each pair and x.offsetWidth
is the same for each pair.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lilles Also the testsuite assumptions include "there is no minimum font-size" so we might not be able to test this. I wonder how much breaks (probably in the CSS2 testsuite?) if we remove that assumption…
Reopen to get screen shot in Chrome - failed last time due to an Ubuntu mirror issue. |
Results are at https://wpt.fyi/results/css/css-values/percentage-rem-low.html?label=pr_head&max-count=1&pr=18941 (same link will work after updates, just check that the commit sha is the same to be sure you're seeing the right results) |
The expected and actual results in Chrome look very similar to me, I can't spot what the difference is... I think this is actually a known issue that @Hexcles has told me about, that when there are multiple references we'll just pick the first or the last to show. If it's possible to express this test with just a single ref that should match, I think that'd be the most robust. |
@gsnedders @foolip FYI, my latest commit results shows that the test pass in firefox, as expected. And fails in Chrome, as expected. In Safari the test fails but not only is the square too big but the ref text, which is styled with https://wpt.fyi/results/css/css-values/percentage-rem-low.html?label=pr_head&max-count=1&pr=18941 Should I change the ref text styling to I'm not sure if there is a test for |
Yes, locking down variations in the ref file is a good idea, even if those variations are because of a bug in some browser or a lack of interoperability. Those things should then be tested separately, but you're not on the hook to add those tests yourself just because you noticed the problem. It would be appreciated though, of course. In a separate PR if so. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Getting very close to greatness :)
@dotnetCarpenter I saw your IRC messages when you were already offline, so I'm asking here. Re:
I'm not sure if you are talking about the test page or the reftest viewer on wpt.fyi. If you are seeing different rendering of the same wpt.fyi URL on different browsers, please let me know. It's definitely a bug. Browser caching shouldn't cause this, either. |
Sorry for the delay. I moved country and didn't have time to update until now. The positively frustrating part is that this particular instance of the bug Edit I take that back. It's fixed in 79.0.3942 not in 77.0.3865. I'm gonna go get some sleep. 💤 I'll check back again tomorrow afternoon. The Trevor Burnham test still fails in Chrome though. https://codepen.io/TrevorBurnham/pen/VXqoEW I currently only have Windows and Linux, so I can not test Safari at the moment. |
@lilles I tried to set root |
@foolip I think this can be merged in now? |
@dotnetCarpenter I saw you requested review from @lilles and was waiting for that, but OK, merge merge away! |
Sorry, my bad. I was requesting review from any of you guys to approve. Thanks for merging! |
This test sets the
font-size
of the:root
element to 20%, which according to spec means that31.25rem
=100px
. This test assumes that the initial value of thefont-size
property is 16px, as observed in desktop Chrome, Opera, Safari, Firefox, IE and Edge.This test fails in current Chrome (78.0.3904.7) as explained here: https://lists.w3.org/Archives/Public/public-test-infra/2019JulSep/0002.html and https://bugs.chromium.org/p/chromium/issues/detail?id=308862.
And probably also Webkit Safari - see https://bugs.webkit.org/show_bug.cgi?id=117680
Test passes in Edge, IE10, IE11 and Firefox
Spec: https://www.w3.org/TR/css-values-3/#rem
Note about current browser differences: AFAIK Internet Explorer and Firefox has always passed this test. Webkit was the only engine to fail. Since blink was forked from Webkit, this test now also fails in Chrome, Opera etc. The percentage scale bug is pre blink.