Main menu does not render correctly after using “Make text bigger” option in desktop Safari

[simevidas]

Steps to reproduce:

1. Use Safari on macOS
2. Navigate to https://www.w3.org/
3. Press [Command] [Option] [+] to “make text bigger”
4. Click the main menu button to open the menu

Notice how the main menu does not render correctly in this video:

Screen.Recording.2023-06-22.at.16.11.45.mov

[deniak]

Indeed, the menu appears correctly only after decreasing the size of the window.

@NicolaSaunders it looks like the mediaqueries values don't match the default breakpoint on safari...
I'm guessing increasing the fonts messes up the conversion. I wonder if using the same units could solve the issue.

[NicolaSaunders]

This appears to be a long-standing Safari bug.

Zooming the entire page (using [command] [+] keys) the CSS media queries (using the em unit) are respected.
When zooming text only (using [Command] [Option] [+] ) Safari is not updating the em value for the CSS media queries, and so is acting as though the screen size has not changed at all.

This JSFiddle also illustrates the problem: https://jsfiddle.net/raubx6p7/

The same behaviour can be seen on other major websites in Safari when zooming the text only rather than zooming the entire page.

[simevidas]

I’m not sure that’s the correct bug. That bug is about em-based media queries not working correctly when the page is zoomed. So it’s about regular zoom, not the “Make text bigger” feature.

I’ve tested your jsfiddle. It seems that ”Make text bigger” does not update em values in media queries. So the equation 1em = 16px stays the same, and the viewport width also stays the same, and that’s why no media query changes occur when making text bigger and smaller, as seen in the video below.

The question is, should em update? “Make text bigger” is a proprietary Safari feature. It’s not part of the web standards. It’s a feature that changes the rendered text sizes in Safari, but how that is implemented is up to Apple.

It have actually thought about this before, and my theory is that Safari adjusts the used font-size values (not the computed values), which would mean that it happens very late in CSS value processing, and that would explain why em stays the same.

Screen.Recording.2023-06-23.at.16.03.11.mov

[NicolaSaunders]

Well, I'm definitely not an expert on the processing of CSS values! So I cannot comment on your theory.

“Make text bigger” is a proprietary Safari feature. It’s not part of the web standards. It’s a feature that changes the rendered text sizes in Safari, but how that is implemented is up to Apple.

That's true. In Chrome the options for increasing font size via Settings are limited (with options for "Large" and "Very large") but doing so still does not cause the same problems that you have spotted in Safari. The same is true of Firefox (which offers a broader range of font size options).

[simevidas]

Yes, changing the default font size in Chrome and Firefox does affect the value of em in media queries.

I suspect that Apple’s goal with “Make text bigger” was to really only make the text bigger and affect nothing else, and that’s why they decided to keep em the same. Some websites use em values for layout (e.g., aside { width: 20em }), so changing the value of em would change the layout of such websites. Apple didn’t want “Make text bigger” to affect layout. That’s my guess.

[NicolaSaunders]

Are you happy if we close this issue now?

[simevidas]

I don’t think this issue should be closed. I suspect that Apple’s view is that “Make text bigger” works as intended. That would mean that the issue with the menu on w3.org would need to be fixed by the website, if that’s possible. If that’s not possible, than that needs to be reported to Apple.

[vivienlacourba]

cc: @svgeesus who might have some guidance on how to address this problem.

[svgeesus]

I don't really agree with Apple's reasoning here but agree that they see it as intended behavior; so they won't fix it in Safari. So if we want to work around this, it needs to be on our side.

[cookiecrook]

@simevidas wrote:

I suspect that Apple’s view is that “Make text bigger” works as intended.

and @svgeesus wrote:

I don't really agree with Apple's reasoning here but agree that they see it as intended behavior; so they won't fix it in Safari. So if we want to work around this, it needs to be on our side.

Is there a particular statement of reasoning from another Apple rep you're referencing? I suspect it's just a WebKit bug limited to Media Queries. Case in point: em sizes have been useable for at least 20 years in responsive layouts:

main {
  width: 800px;
  min-width: 25em;
}

…so if there was an ulterior motive for preventing em from working with the "Make Text Bigger/Smaller" feature, that should have also been removed, and I would have personally objected due to accessibility reasons.

[simevidas]

In an earlier comment I said that “Make text bigger” (MTB) does not change the value of em. That was wrong. I made that incorrect conclusion because I noticed that px-sized text also becomes larger, which led me to think that MTB must be doing something other than just increase em. That alone would not affect px-sized text.

After some more testing, I observed that MTB does increase the value of em (first to 120%, then to 144%), but it also makes px-sized text render larger. How Safari does this, I don’t know. I don’t see anything in WebKit Inspector that would explain why the computed value is 20% larger than the declared value (see screenshot below). I guess MTB runs a special function that updates fon-size px values for every element on the page.

So the fact that MTB changes the value of em in declarations but not in media queries must be a bug. That just doesn’t make any sense to me.

Test page: https://output.jsbin.com/gacohuy/quiet (resize the viewport before/after using MTB)

[command] [option] [+] = Make text bigger
[command] [0] = reset to default size

[NicolaSaunders]

Thanks everybody. I personally still think it is related to https://bugs.webkit.org/show_bug.cgi?id=41063.

Please can somebody confirm whether they are happy to pass on all the details to the the Apple/safari team, and whether this issue can be closed as it will not be resolved on our side?

[simevidas]

I’ve filed a new WebKit bug here:

https://bugs.webkit.org/show_bug.cgi?id=258619

I think this issue can be closed now.

[NicolaSaunders]

Thank you very much @simevidas - I am now closing this issue.