Steps to reproduce
Viewing the site https://polished.js.org/docs/
A max-width of 64 rems is applied to the page (base font size is set at 16px). This should result in a maximum page width of 1024px.
Chromium Edge is displaying this at 832px
Steps to produce
- Visit the URL https://polished.js.org/docs/
- Expand the viewport as wide as is possible on your device
- Observe that the width of the container does not extend passed 832px
- Observe that the left navigation bar scroll bar overlaps the main content
The container expands to a maximum width of 1024 at 1dpi and 16px base font.
The container only expands to 832px, subsequently the % values then appears to be calculated incorrectly.
The width of the navigation bar is 25% and the main content has a margin left of 25%. I’m aware the left navigation has a position fixed and this may be causing some of the issues?
Browsers tested in:
Chrome (latest stable)
Firefox (latest stable)
Edge (latest stable)
Able to replicate in none of the above
Comments and activity
Chromium Edge seemingly ignores abolute font-size declaration in the
bodyelement for ALL rem-based font-size properties, not only for container-width.
If calculates the rem-size from the font-size property of the
htmltag. If there isn’t an absolute font-size specified, Chromium Edge defaults all rem calculations on 13px.
- Microsoft Edge Team
Changed Assigned To to “Zachariah L.”
Changed Assigned To to “Arvind M.”
set up a nested media query at 160px intervals that changed the content of a :before pseudoelement to reflect width stops. Set up another nested set at 8rem with root font-size set to 20px. This time the content of an ::after pseudoelement was set to change at the rem-based width stops.
When sliding the window size, the ::before content was changing at 160 pixel intervals as set in the media query. These queries were behaving as expected from the px media stops. The ::after element was however changing roughly at the following stops: 253px, 128px, 130px, 127px, 130px, 127px, 127px… the intervals should have been a consistent 160px. Safari, Chrome and Firefox behave as expected.
This issue breaks the correlation between rem media query lengths and lengths for background-image sizing, box sizing, font-sizing etc…