You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
@media rule thresholds do not account for browser font size setting #9390
I have read the console error message carefully (if applicable).
Description
Most things in docusaurus scale with rem units, but the thresholds for @media rules are set in px. Which means setting a large font size in the browser effectively "zooms in" the page, but the @media rules do not trigger like they would with actual zoom.
Screenshots below are from the page https://docusaurus.io/docs/styling-layout with the same zoom level (100%) and viewport size (~1000px). The large font size breaks the layout.
Set viewport width to ~1000px, just before the @media rule triggers
Set large font size in the browser
Observe the broken layout
Expected behavior
IMHO it would make sense to use rem unit for @media thresholds as it would represent the "actual" scale of the content (accounting for both zoom and browser font size).
Actual behavior
TOC on the right was unreasonably squished and navbar at the top has overlapping text. Normally with the content being enlarged this much a @media rule would trigger, but it does not happen because the threshold is tied to px and is not aware of browser font size setting.
The bug occurs because the size of elements on the page is tied to rem units, which are affected by font size setting in (any) browser. By default 1rem = 16px so these units are in a sense equivalent. However, setting large font size in the browser will change this ratio (e.g. 1rem = 32px).
This effectively zooms in the page, because everything is tied to rem in docusaurus CSS (e.g. 1rem margin used to be 16px and now it is 32px). However, @media rules are tied to px units which are unaffected by font size and so they are "unaware" of the layout getting compressed.
I'm not sure what to do. Sites like GitHub and nextjs.org seem to have fixed font size so their sites don't rescale at all. Vuepress only scales the navbar but not the content, and its screen size breakpoint is also based on pixels. Do you have a site showing ideal behavior?
I'm not sure what to do. Sites like GitHub and nextjs.org seem to have fixed font size so their sites don't rescale at all. Vuepress only scales the navbar but not the content, and its screen size breakpoint is also based on pixels. Do you have a site showing ideal behavior?
I will try to find an example (or make one myself). But by simply experimenting with developer tools in browser, replacing
@media (max-width: 996px) {
with
@media (max-width: 62.25rem) {
seems to do the trick. As long as the default setting 1rem = 16px remains in place, these rules are equivalent. If the font size (ratio rem to px) is increased, the rule triggers earlier (which is desired to prevent the layout from breaking).
The only issue is that I can't be sure this change won't unexpectedly create problems elsewhere (theoretically I don't think it should).
Unless I'm missing something, simply replacing all media thresholds defined in px with 1/16 of that value in rem should provide ideal behavior, and look exactly the same as before with default font setting.
Speaking of which, searching for @media rules in the repo I found thresholds of 996px and 997px being used seemingly interchangeably. Not sure if this is intentional. Either way this is unlikely to cause serious issues but IMHO is confusing and could lead to weird situations in edge-case scenarios where the viewport is exactly 996px and only half the page is in compact mode.
It makes sense to me, but I'm not sure if it will cause problems elsewhere. For example, we also have JavaScript code that use the 996 boundary (soon to be configurable, but pixel-based nonetheless):
I found a few examples of pages that use em or rem for @media rules (as well as for most sizes/margins, like docusaurus does). It works as expected, the @media rules being aware of extra scaling introduced by altered font size setting in the browser.
Activity
Piyush-onGIT commentedon Oct 11, 2023
Please assign me this issue, I would like to work on this.
OzakIOne commentedon Oct 11, 2023
Docusaurus maintainers don't assign issue to people, if you want to contribute, just send a PR
slorber commentedon Oct 12, 2023
Isn't this a Brave-only issue?
Because despite using px I see Chrome, Firefox and Safari being able to switch to the mobile layout on zoom.
CleanShot.2023-10-12.at.11.14.40.mp4
KosRud commentedon Oct 12, 2023
Have you set large font size?
slorber commentedon Oct 12, 2023
I don't use Brave. Can you show me where to find this option on other browsers and tell me if you see the bug in other browsers too?
KosRud commentedon Oct 12, 2023
I just installed Chrome and it does appear there too. Below is screenshot of the bug, as well as how to reach the setting.
KosRud commentedon Oct 12, 2023
The bug occurs because the size of elements on the page is tied to
remunits, which are affected by font size setting in (any) browser. By default1rem = 16pxso these units are in a sense equivalent. However, setting large font size in the browser will change this ratio (e.g.1rem = 32px).This effectively zooms in the page, because everything is tied to
remin docusaurus CSS (e.g.1remmargin used to be16pxand now it is32px). However,@mediarules are tied topxunits which are unaffected by font size and so they are "unaware" of the layout getting compressed.Josh-Cena commentedon Oct 12, 2023
I'm not sure what to do. Sites like GitHub and nextjs.org seem to have fixed font size so their sites don't rescale at all. Vuepress only scales the navbar but not the content, and its screen size breakpoint is also based on pixels. Do you have a site showing ideal behavior?
KosRud commentedon Oct 12, 2023
I will try to find an example (or make one myself). But by simply experimenting with developer tools in browser, replacing
with
seems to do the trick. As long as the default setting
1rem = 16pxremains in place, these rules are equivalent. If the font size (ratioremtopx) is increased, the rule triggers earlier (which is desired to prevent the layout from breaking).The only issue is that I can't be sure this change won't unexpectedly create problems elsewhere (theoretically I don't think it should).
Unless I'm missing something, simply replacing all media thresholds defined in
pxwith 1/16 of that value inremshould provide ideal behavior, and look exactly the same as before with default font setting.KosRud commentedon Oct 12, 2023
Speaking of which, searching for
@mediarules in the repo I found thresholds of996pxand997pxbeing used seemingly interchangeably. Not sure if this is intentional. Either way this is unlikely to cause serious issues but IMHO is confusing and could lead to weird situations in edge-case scenarios where the viewport is exactly996pxand only half the page is in compact mode.https://github.com/facebook/docusaurus/blob/ae3191654cc8022da39c5c425bc3dca85bf0314f/packages/docusaurus-theme-classic/src/theme/TOC/styles.module.css#L15
https://github.com/facebook/docusaurus/blob/ae3191654cc8022da39c5c425bc3dca85bf0314f/packages/docusaurus-theme-classic/src/theme/DocRoot/Layout/Sidebar/styles.module.css#L17
https://github.com/facebook/docusaurus/blob/ae3191654cc8022da39c5c425bc3dca85bf0314f/packages/docusaurus-theme-classic/src/theme/BlogSidebar/Desktop/styles.module.css#L41
https://github.com/facebook/docusaurus/blob/ae3191654cc8022da39c5c425bc3dca85bf0314f/packages/docusaurus-theme-classic/src/theme/DocSidebar/Desktop/Content/styles.module.css#L8
Josh-Cena commentedon Oct 12, 2023
@KosRud
max-width: 996pxis equivalent tomin-width: 997px, because the breakpoint is inclusive :)KosRud commentedon Oct 12, 2023
@Josh-Cena
My bad, you are right. I missed that one is max and another is min.
Regarding the potential fix, does replacing the
pxthresholds with 1/16 inremsound reasonable?Josh-Cena commentedon Oct 12, 2023
It makes sense to me, but I'm not sure if it will cause problems elsewhere. For example, we also have JavaScript code that use the 996 boundary (soon to be configurable, but pixel-based nonetheless):
https://github.com/facebook/docusaurus/blob/ae3191654cc8022da39c5c425bc3dca85bf0314f/packages/docusaurus-theme-common/src/hooks/useWindowSize.ts#L20-L29
Therefore, I'd still be curious to know what the best practice is and examples of such.
KosRud commentedon Oct 12, 2023
@Josh-Cena
I found a few examples of pages that use
emorremfor@mediarules (as well as for most sizes/margins, like docusaurus does). It works as expected, the@mediarules being aware of extra scaling introduced by altered font size setting in the browser.https://www.ada.gov/resources/web-guidance/

https://www.goodemailcode.com/email-accessibility/rem-and-em.html

https://www.w3.org/WAI/fundamentals/accessibility-intro/

https://drafts.csswg.org/mediaqueries/
This page also uses
emfor@mediathresholds, but it also appears to use some javascript in conjunction with@mediarules.Josh-Cena commentedon Oct 13, 2023
Thanks! I think the CSSWG website is convincing enough that we should do something similar.