Steps to reproduce: 1. Add this CSS to the page: html { font: -apple-system-body; } 2. Observe that the default text size in Safari on macOS is 13px. Live demo: https://output.jsbin.com/nofobeh/quiet Why 13px? That’s a reduction of 3px from the usual default of 16px. This is a problem for websites that want to use -apple-system-body in order to support the text size accessibility preference on iOS. How should such websites handle the 13px default in desktop Safari?
<rdar://problem/83195793>
This matches platform conventions on macOS.
If you want, you can do something like: <style> :root { font -apple-system-body; } #myElement { font-size: 130rem; }
The problem is that on every other platform and browser, the default font size is 16px, so if I use em or rem units to increase the font-size for desktop Safari, it will be too big in all other browsers. html { font: -apple-system-body; } body { font-size: 1.2307692rem; } With this code, the font-size will by default be exactly 16px in desktop Safari but 19.69px in all other browsers (including iOS Safari!). The only way to get a consistent 16px across all browsers seems to be to detect desktop Safari and add the body font-size: 1.2307692rem increase to that browser only. Since there is no “Larger text” accessibility setting on macOS, I think it would be best if font: -apple-system-body was just ignored and didn’t result in a font-size decrease to 13px.
You should be able to use @supports with font: -apple-system-body to conditionalize the size adjustments. CSS variables will also help here. The purpose of -apple-system-body is to match platform conventions to allow content to show UI that looks like native UI. Putting -apple-system-body in a WKWebView and putting that next to native UI in an app needs to result in them having the same size. https://github.com/w3c/csswg-drafts/issues/3708 has a bunch of other ideas for new ways to expose the dynamic text size of the system. Maybe you’re advocating for something new, rather than adjusting the behavior of -apple-system-body? If there is to be a new mechanism, it should probably go to the CSSWG first, rather than start in WebKit’s bug tracker.