Closed litherum closed 3 years ago
litherum
commented
5 years ago WebKit's current implementation is intended to work like this:
body {
font: -apple-system-body;
}
h1 {
font-size: 1.2rem;
}This is a good place to start the conversation at.
myakura
commented
5 years ago Android also has the system font size feature and it appears to work just as iOS/Windows; it applies across the OS but the content inside browser.
I've wanted the font size exposed to the web. During holidays I was helping my mother setting up her phones, and she wanted the bigger UI text so I changed the size. However some contents on the homescreen were pinned websites so those "UI"s are not scaled to the size she wanted.
So I would really love to see the standardized solution. It improves accessibility for elderly people (or people with decreasing vision) and will also supports people like me who wants to make UI size smaller.
litherum
commented
5 years ago @myakura Yep, looks like Android has this setting, too.
AmeliaBR
commented
5 years ago What do you expect to be added to CSS?
This isn't really a new problem. Historically, most browsers allowed users to set preferred font-sizes; Chrome and Firefox still do. All that is changing is that the setting has moved from the browser to the operating system.
Wherever the user preference is set, it should be reflected by the browser in the default font size for the page (and the definitions of the font-size keywords like medium, as discussed in https://github.com/w3c/csswg-drafts/issues/2430).
Ideally, web page content authors would work with that user preference, using medium font (or 1rem assuming that they never mess with the root font size) for normal body text, and relative adjustments from that value for fancy fonts, headings, small text, and so on.
But web page authors, as a whole, have historically been very bad at reflecting user's preferred font sizes…
As you mention, simply overriding the font size set by the web page styles can result in broken layout and overlapping text, which is why most browsers don't override absolute font sizes. But at least some browsers (Firefox and Chrome) currently support a "minimum font size". There's no reason they couldn't adjust that automatically based on an OS-set ideal font size, if the user hadn't set a different value in the browser.
The only option that would avoid potential clashes with author styles would be for a browser to be smart about setting the overall px-zoom level for a page to effectively scale up/down body text to within a certain percentage of the preferred size. But I'm skeptical about whether this type of smarts could really be implemented correctly and efficiently, given the wide variety of font styles and effective sizes for a given em-size.
Malvoz
commented
5 years ago This was also mentioned in https://github.com/w3c/csswg-drafts/issues/2630 / https://github.com/w3c/csswg-drafts/issues/1693. Might aswell keep the discussion here?
cookiecrook
commented
5 years ago @AmeliaBR wrote:
What do you expect to be added to CSS?
A number of potential solutions could solve this problem.
Minimum Needs
1. A way for authors to opt-in to the user's preferred font size. This might be achieved using existing ways (e.g. font-size: medium though probably with another opt-in) or new ways (e.g. font-size: env(font-size) to set an element's font size (such as the body base font size) to a user's preferred default.
2. A way to ensure browsers don't force this on web sites (especially mobile sites) that are not prepared or able to fix layout issues. Turning this on everywhere will break most mobile web layouts, and make the feature unusable for the low vision users who need it the most. Potential solutions to this might include a new viewport property (e.g. supports-large-fonts or something similar) as an explicit opt-in. A new keyword (system-font-size) or accessor (env(font-size)) could also count as an explicit opt-in.
3. A way for authors to adapt their layouts to changes in the user's font-size. This should probably be handled by media queries. More on this below.
This isn't really a new problem. Historically, most browsers allowed users to set preferred font-sizes; Chrome and Firefox still do.
As does Safari on Mac. The newer problem is more specific to mobile contexts where screen real estate is more constrained.
Wherever the user preference is set, it should be reflected by the browser in the default font size for the page (and the definitions of the font-size keywords like medium, as discussed in #2430). >Ideally, web page content authors would work with that user preference, using medium font (or 1rem assuming that they never mess with the root font size) for normal body text, and relative adjustments from that value for fancy fonts, headings, small text, and so on.
But web page authors, as a whole, have historically been very bad at reflecting user's preferred font sizes…
This is the problem. Most sites would break, and the user would be forced to turn off this exceedingly useful system feature.
Apple engineers underwent a huge engineering effort in 2017 to make sure the entirety of iOS supported the extra-large accessibility font sizes. The entire Web will never support extra extra large fonts, but low vision users should have the ability to use this feature in apps and sites that take the care to do it the right way.
As you mention, simply overriding the font size set by the web page styles can result in broken layout and overlapping text, which is why most browsers don't override absolute font sizes. But at least some browsers (Firefox and Chrome) currently support a "minimum font size".
Safari has also had this preference for more than a decade. It would be irrelevant to the mobile context unless authors were provided a way to opt-in and a way to adapt their sites.
There's no reason they couldn't adjust that automatically based on an OS-set ideal font size, if the user hadn't set a different value in the browser. The only option that would avoid potential clashes with author styles would be for a browser to be smart about setting the overall px-zoom level for a page to effectively scale up/down body text to within a certain percentage of the preferred size. But I'm skeptical about whether this type of smarts could really be implemented correctly and efficiently, given the wide variety of font styles and effective sizes for a given em-size.
There are a number of common layouts that would make existing CSS impractical or impossible on small viewports. I'll start with a straightforward example previously pitched to the CSS WG.
/* Default layout uses 2 columns */
main {
columns: 2;
}
/* But if the user's default font size (from browser text zoom setting or... */
/* user style sheet...) is larger than 32px, drop the columns. */
/* Old Note: the CSS MQ Level 3 syntax is (min-user-font-size: 32) */
/* Old Note: this example uses the greater-than/less-than syntax likely to be adopted by CSS MQ4. */
@media (user-font-size > 32) {
main {
columns: auto;
}
}Other syntax ideas we've discussed include:
1. Reuse system-ui in other font contexts not limited to font-family.
font-size: system-ui;2. Use a new keyword.
font-size: system-font-size; Incidentally a new keyword could be used in the shorthand as well:
font: system-font-size system-ui black;And potentially as a font-size media feature:
@media (system-font-size > 32px) {
/* Reduced layout from 2-column to 1-column, for example. */
}3. Use a generic accessor of user preferences. IIRC, Tab Atkins proposed something like this in 2015 or 2016.
font-size: user(font-size);
@media (user(font-size) > 32px) { }…but env() is likely more practical now than the last example.
clshortfuse
commented
5 years ago Apple is actually following the specifications for system fonts as laid out in CSS Fonts Module Level 3
System fonts may only be set as a whole; that is, the font family, size, weight, style, etc. are all set at the same time. These values may then be altered individually if desired. If no font with the indicated characteristics exists on a given platform, the user agent should either intelligently substitute (e.g., a smaller version of the ‘caption’ font might be used for the ‘small-caption’ font), or substitute a user agent default font. As for regular fonts, if, for a system font, any of the individual properties are not part of the operating system's available user preferences, those properties should be set to their initial values.
https://drafts.csswg.org/css-fonts-3/#font-prop
The specification goes to list some examples of font values for system fonts:
font: menu; /* use the font settings for system menus */
font: large menu; /* use a font family named "menu" */I didn't see anything exclusive whitelist to the names. I think the property needs a bit more attention.
As for the base font size, the reality is all major desktop browsers scale it based on user setings: Chrome, Safari, FireFox, Edge and Internet Explorer. They have done so for decades. It's mobile browsers (Safari, Chrome, and FireFox) that have locked up the HTML element to 16px and not something based on the system font-size. FireFox on Android actually lets you use "System Font Size" which allows rem to work properly. It's up to the user agent to provide the functionality.
Despite forcing 16px for the HTML element, Apple decided to still allow you to access the system font size (and type-face), but with an opt-in font CSS declaration. I'm not sure if more standards and newer options are the answer. (The media queries stuff does seem useful for other things though.) In reality, I would think it would be simpler to instruct the browser it doesn't need to break the standards we've already had in place since CSS2 (font-size:medium is the reference point that is usually 16px font.) Perhaps a meta tag in the head that instructs the browser to apply the same font standards as it would on desktop?
It's really about getting browsers to comply with the standards already in place. For example, W3 has already set a user-agent checkpoint for this in place back in 2002.
4.1 Configure text scale (P1) Allow global configuration of the scale of visually rendered text content. Preserve distinctions in the size of rendered text as the user increases or decreases the scale. As part of satisfying provision one of this checkpoint, provide a configuration option to override rendered text sizes specified by the author or user agent defaults. As part of satisfying provision one of this checkpoint, offer a range of text sizes to the user that includes at least:
- the range offered by the conventional utility available in the operating environment that allows users to choose the text size (e.g., the font size), or
- if no such utility is available, the range of text sizes supported by the conventional APIs of the operating environment for drawing text.
https://www.w3.org/TR/WAI-USERAGENT/guidelines.html#tech-configure-text-scale
Apple has a workaround for this as stated and W3 included the workaround in their guidelines
As for Chrome on Android, it fails. If Google can fix it moving forward, then I honestly don't see the need to create another standard. IMO, a standard font:-android-system-font would work fine and follows the W3 standards. If W3 wants to create a new declaration such as font:system that works for me too.
tabatkins
commented
5 years ago As @clshortfuse says, desktop browsers all respect the user's default font-size, and have for decades. Some pages break, but most are fine. Is the mobile web so substantially different in this regard?
(That said, if it turns out this is the case, my preferred solution is an env() value, not a system font. System fonts are big hammers and very awkward to use, particularly in cases like this where the only thing it's trying to communicate is a font size.)
clshortfuse
commented
5 years ago @tabatkins Getting the whole font has its uses though.
Most of the time, web authors will change the font, but there are situations where you want the website to look native (Electron Apps or PWAs). Then you sometimes don't want your dialogs, menus, or other component to look any different than system ones. I think that was the original intention of font back in CSS 2.1. The only problem is there was nothing states for body; there was only caption, icon, menu, message-box, small-caption and status-bar. There was no dedicated value for just the regular font. There's also the case that font-family has no specification. It's up to the user-agent. For example, Chrome on Mac OS X defaults to font-family:Times and not the system font. Nothing in the W3 spec says font-family should initialized as Times, and yet, here we are.
https://drafts.csswg.org/css-fonts-3/#propdef-font-family
At least we now have font-family: system-ui which is part of CSS Font-4. That formalized a solution and did away with people having to use font-family: -apple-system.
https://drafts.csswg.org/css-fonts-4/#valdef-font-family-system-ui
While font is a big sledgehammer to the problem, it can easily be reset back however you'd like. In fact, by using the Apple's proprietary value, you are subject to whatever Apple decides to change about the font in future. You should be overriding it anyway. You can easily override anything you don't want to be used in the next line after the declaration, like so:
html {
font: system;
/** Reset everything else **/
font-style: initial;
font-variant: initial;
font-weight: initial;
font-stretch: initial;
/** font-size: initial; **/
line-height: initial;
font-family: initial;
}Personally, I would override everything but font-size. There's also the case where the system font-variant may be useful. I think East-Asian languages have stronger benefit from this. Also if somebody wants to write a Web App (PWA) that would let somebody use that funky italic font on their Samsung if it's the system default, then they can. 😆
But just to reiterate, the current specification (in CSS Fonts 4) for font's value is :
[ [ <font-style> || <font-variant-css2> || <font-weight> || <font-stretch-css3> ]? <font-size> [ / <line-height> ]? <font-family> ] | caption | icon | menu | message-box | small-caption | status-bar
If it were:
[ [ <font-style> || <font-variant-css2> || <font-weight> || <font-stretch-css3> ]? <font-size> [ / <line-height> ]? <font-family> ] | caption | icon | menu | message-box | small-caption | status-bar | system
I'll be happy.
cookiecrook
commented
5 years ago @tabatkins wrote:
System fonts are big hammers and very awkward to use, particularly in cases like this where the only thing it's trying to communicate is a font size.
In addition the points above made by @clshortfuse, here's a specific example where this would be used for more than just font size. iOS has a system-wide setting to enable bold text*, which is reflected in the system weight. I don't have a preference for system-font versus env(), but all aspects should be ideally be retained.
@clshortfuse wrote:
html { font: system; font-weight: initial; }
Aside FYI, resetting the user's preferred font weight may be an anti-pattern. Legally blind users and contrast-deficient users often enable this setting to increase text contrast to more perceivable levels.
cookiecrook
commented
5 years ago @tabatkins wrote:
As @clshortfuse says, desktop browsers all respect the user's default font-size, and have for decades. Some pages break, but most are fine.
I'd disagree that most are fine. Browsers all used to have an "enlarge text" method that most have abandoned because web sites implemented it so poorly. Now most browsers (including Safari) default to viewport zoom on the entire page, scaling images and block layout, too. The desktop viewport zoom you've mentioned ("most [sites] are fine") is directly equivalent to mobile viewport zoom, and so it's irrelevant to the font size discussion. This feature is already available on mobile via "pinch to zoom", "double-tap to zoom", and other ways.
Safari for Mac also retains a way to view the old "enlarge text only" behavior. Try it, and you'll see how much these CSS additions are needed. Either hold down "Option" while expanding the View menu, or use the hotkeys: Cmd+Opt+Shift+Plus/Minus.
When I enlarge the text to its largest size (rather than zooming the viewport), almost every site I tried had overlapping text and horribly broken layouts: Yahoo, New York Times, Gmail, ESPN, Netflix, Hulu, CNN, Wikipedia, Amazon, etc. They're all broken to the point that they are unreadable and unusable. Only one of the sites I tried, BBC, adjusted its layout reasonably, and it took a page refresh to get it right.
Even when web developers know about the problems, some layouts would not be possible to adjust properly, even with current techniques of responsive web design. For example, setting a block-level element's min-height and/or min-width to EM or REM units can get sometimes get you to a mediocre stop-gap solution, but it doesn't allow one to adjust complex layouts sufficiently.
Is the mobile web so substantially different in this regard?
Yes, substantially, because the viewports and screens are so much smaller than desktop displays.
Standard viewport zoom is already available to mobile users through "pinch to zoom" and other means. Mobile browsers could automatically zoom the viewport to match the user's preferred font size (as all desktop browsers do), but that would 1) cause excessive amounts of horizontal scrolling on mobile, and 2) provide absolutely no utility over existing methods of viewport zooming.
If mobile browsers applied extra large system font sizes to mobile, it would break the layout of almost all web sites. The experience would be so bad that users would have to turn off the feature entirely while using the web.
Native apps on mobile would similarly be broken if the large sizes were forced on them, so they aren't applied to apps automatically. App developers need to opt-in to supporting the larger font sizes. WWDC 2017 included a session on the iOS API called Building Apps with Dynamic Type.
cookiecrook
commented
5 years ago Footnote to this comment:
WWDC 2017 included a session on the iOS API called Building Apps with Dynamic Type.
Some of the layout changes discussed in that session would be impossible to achieve with current CSS techniques. At a minimum, the ability to reference user font size in a media query would be necessary to achieve some of the text size adaptation techniques that are used in native apps in iOS 10 and later.
clshortfuse
commented
5 years ago After closer analysis, there is nothing in the the actual W3C papers that state that the browser must be using the system font size as default. In fact, nothing says it has to be 16px either. medium is also just a starting reference point and that's up to the user-agent.
So, while desktop browsers applied the root element to use the system font size, that wasn't really part of the spec. Mobile browsers don't have to. But, because of that, applying W3C WAI's best practices for WCAG 1.4.4 becomes impossible on Chrome on Android without the authors creating their own custom text-scaling option just for Chrome.
https://www.w3.org/TR/mobile-accessibility-mapping/#zoom-magnification
So I think this implementing this would really solve an accessibility issue that's been plaguing Android users for years now.
I don't know if I should open up another issue specifically targeting system font-size, or perhaps we can reach a consensus on the language of the issue. Perhaps we can rename the title?
AmeliaBR
commented
5 years ago Previous versions of CSS specifically required that “The 'medium' value is the user's preferred font size.” That requirement was somehow lost in the transition to CSS Fonts, and the WG in #2430 decided it wasn't important enough to add back in.
So, a first approach at addressing this issue could be to add that requirement back in, making it clear that the “user's preferred font size” should be taken from system preferences if the browser doesn't offer more direct control.
I personally think that's all that is required. Running through @cookiecrook's list of minimum needs, from above:
A way for authors to opt-in to the user's preferred font size. If authors can be confident that medium is the user's preferred font size, that's the way to do it.
A way to ensure browsers don't force this on web sites (especially mobile sites) that are not prepared or able to fix layout issues. Any website that uses absolute font sizes wouldn't change. (In contrast, if a website only uses relative font sizes but assumes the default will always be 16px, they will be broken already in many browsers.)
A way for authors to adapt their layouts to changes in the user's font-size. A media query that uses em or rem units (@media (min-width: 40em) {…}) would adapt based on the change in default font size.
jonjohnjohnson
commented
5 years ago clshortfuse
commented
5 years ago @AmeliaBR The user may prefer a certain size for their web-browser that may be different than system. For example, if you scale the font in Chrome on desktop to "Very Large" medium will change to 24px. AFAIK, Mac OS X doesn't let you just scale text like you can on iOS or Windows. This makes me believe that there are many that have different browser (user-agent) preferred size than the system one.
It doesn't solve the issue that Chrome on mobile doesn't allow you change the user's specified font-size. Also, for PWAs that want to look "native", you might still want the system font-size (or even style). You can accomplish this with -apple-system-body, but that's not part of any spec and it is Mac/iOS exclusive.
AmeliaBR
commented
5 years ago that's not part of any spec
System fonts that include font size are part of the spec for the font shorthand property. The (See corrections in following comments)-apple-system-* font keywords are unique because they map to a font family without specifying a font size or bold/italic etc.
Chrome on mobile doesn't allow you change the user's specified font-size.
Which is a limitation of the browser UI, not a limitation of the spec.
clshortfuse
commented
5 years ago @AmeliaBR
System fonts that include font size are part of the spec for the font shorthand property. The -apple-system-* font keywords are unique because they map to a font family without specifying a font size or bold/italic etc.
Unless I'm misunderstanding your comment, -apple-system-body does change the font-size. That's really the way Dynamic Type works. You set it in iOS settings and then any Safari page that uses that font property will get all the font styles. I explained this a bit better in a previous. https://github.com/w3c/csswg-drafts/issues/3708#issuecomment-477433666
This Webkit blog entry states:
These text styles identify more than simply a particular font family; instead, they represent an entire style, including size and weight.
@cookiecrook Also made a great point that an OS can have system-wide bold/italic setting:
iOS has a system-wide setting to enable bold text*, which is reflected in the system weight.
That's why I'm advocating for font: system which would have more benefits. That's also why I was unsure if I should open up another issue that is specifically targeting the entire system font, versus just the font-size.
Which is a limitation of the browser UI, not a limitation of the spec.
The problem is, there's no spec for how and when to use the default system font size, so any implementation of it would be custom. I came across this issue because I directed here by the Chromium team.
https://bugs.chromium.org/p/chromium/issues/detail?id=942045#c17
Which basically translates, if this is added to spec, then it can be added to Chrome. And I fully understand the team's position, being that it's better to see if W3C can reach a consensus how it can be implemented, and then implement it into the browser. I'm assuming they want to avoid adding something proprietary like Apple did.
AmeliaBR
commented
5 years ago @clshortfuse Apologies, I was clearly confusing the apple system font keyword with the font family keywords used on other systems like Android. So, font: -apple-system-body does work the same as font: caption and the other shorthand keywords. That's definitely something that could be standardized, if there's demand for it.
For reference, the current shorthand font keywords in the spec are:
- caption
- The font used for captioned controls (e.g., buttons, drop-downs, etc.).
- icon
- The font used to label icons.
- menu
- The font used in menus (e.g., dropdown menus and menu lists).
- message-box
- The font used in dialog boxes.
- small-caption
- The font used for labeling small controls.
- status-bar
- The font used in window status bars.
So they're focused on form elements, but don't cover general text content. Adding a system-body or body-text keyword does make sense.
But I don't see how that addresses the general problem of setting font-size according to the user preference, without an OS-themed font family. Are you suggesting that authors use font: system; font-family: my-web-font;, to indirectly set the font size & then reset it? Or are you suggesting that separate mechanisms are required?
AmeliaBR
commented
5 years ago if this is added to spec, then it can be added to Chrome
If I'm reading that issue correctly, it would be addressed by my recommendation above, to reinstate the requirement that the default/medium font-size must match user preferences, with an added clarification that an OS-level preference should be used unless the browser offers its own preference mechanism.
But it sounds like you want the spec to go a step further, and state that user agents should provide their own direct user control for the default font-size? I wouldn't mind that, but given the response to the last discussion about this (#2430), I'm not sure that the group would agree.
clshortfuse
commented
5 years ago @AmeliaBR Yes, I covered it a bit in this comment. You can also set font-family: initial if you want to keep the browser default. That's actually how cookiecrook caught on that, for accessibility purposes, we shouldn't be resetting font-weight .
But now that I read what you were saying about medium and thinking it over, that wouldn't solve another issue. Mac OS X has no resizing of system font. Even if the user scales up their text in the browser (uses "Very Large"), then font:system should still set it to the whatever Mac OS X uses (San Francisco @ 16px). You may want that for "web apps", but probably not websites. It would work on iOS, Android, and Windows because those operating systems allow font scaling. Unless, we say that font:system can only be implemented on OS's with font-scaling support (most except Mac OS X). But even that gets messy.
That means effectively, we will still need another property for the size itself. I do like font-size:medium, personally, but I think most resistance you'll find is existing content would change. People have, perhaps, already built styles expecting font-size:medium to be 16px on Chrome Mobile and iOS (assuming they're not using Dynamic Type). That means, we unfortunately need a new property, (eg: font-size:preferred or font-size: env(user-font-size)).
Regardless, the property in question should be SYSTEM_FONT_SIZE * BROWSER_FONT_SCALE. On iOS and Android, BROWSER_FONT_SIZE would likely always be 100% with SYSTEM_FONT_SIZE being variable. But on Mac OS X, it would be the opposite. Windows would likely support both. So now I'm envisioning:
html {
/* iOS Dynamic Type */
font: -apple-system-body;
/* New CSS Spec to get system font-family and system font-weight */
font: system;
/* New CSS Spec to get preferred font size Option 1 */
font-size: preferred;
/* New CSS Spec to get preferred font size Option 2 */
font-size: env(user-font-size);
/* Fallback to get system font-family */
font-family: system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, 'Open Sans', 'Helvetica Neue', sans-serif;
}Which would cover a native-like experience (for PWAs or Electron), allow font-scaling on browsers that support it, while providing a fallback for those that don't. (Style authors can always change font-family).
css-meeting-bot
commented
5 years ago The CSS Working Group just discussed Dynamic text size.
litherum
commented
5 years ago In summary, the conclusion of the conversation today:
font: system-body Because this is a shorthand, it sets all the font properties to their OS-provided values. Inheritance works properly, so authors can scale their content by using ems and rems. Setting all the font properties and then immediately overwriting font-family (so just the other properties remain) seems yucky.env(font-size-multiplier) Only exposes a single scalar, so an extra variable is needed for the OS-provided weight. Can be used in any element using calc().font-size: medium to the user's preferred font size. The spec used to dictate this, but it no longer says that. Compat data would be valuable.We didn't talk about a media query or a way to switch to a new layout.
fantasai
commented
5 years ago It was also pointed out that Firefox's default font size for web pages varies by language and generic font family, so length value (or a multiplier intended to be multiplied by 16px? which is what I'm guessing env(font-size-multiplier) is supposed to be) cannot represent the user-preferred defaults.
More generically, the font used in system dialogs and the user's preferred text size for long form content (such as web content) might not be identical: which one are we trying to represent here, and is that really what we want?
kojiishi
commented
5 years ago Thank you for the clarification, at some point I was confused which one we were talking about. What I'm interested in is the font used in system dialogs. Firefox for Android has "Use system font size" option in its Accessibility settings, but authors can't enable it. Safari is the only mobile browser that allows web authors to create such pages today with --apple-system-body. An interoperable way to create such pages would be great.
fantasai
commented
5 years ago Reading through the F2F minutes, it was asserted that there's a compat problem with making the initial value be other than 16px, but it wasn't clear whether mapping the 'medium' keyword to the user's preferred font size was also problematic. (The initial value is currently specced to be 'medium', but this could be decoupled.)
css-meeting-bot
commented
5 years ago The CSS Working Group just discussed Dynamic text size, and agreed to the following:
RESOLVED: There should be a way to have true font sizes.cookiecrook
commented
5 years ago Resolution from the F2F was to have a an opt-in switch for the web authors to get the true user font size, even on small screen device... Ideally the opt-in could be phased out over time if/when the Web handled scalability better.
General consensus was that this should be an addition to <meta viewport>
svgeesus
commented
5 years ago removing css-fonts-5 labe as consensus was to express this via <meta viewport>
AmeliaBR
commented
5 years ago We may still want some clarifying notes added to CSS Fonts. But first we need to spec the new <meta name="viewport"> option. @litherum, I think that one's on you. Especially since there doesn't seem to be any standard documentation for the viewport meta tag beyond Apple's docs, anyway. (See https://github.com/whatwg/html/issues/3494 and https://github.com/whatwg/html/issues/4561 for discussion about getting that into HTML.)
cookiecrook
commented
4 years ago Closing the loop on this. Since the discussions last Fall, iOS Safari has shipped a per-site font size setting, so my understanding is that we no longer need an author opt-in.
chrislachance
commented
3 years ago There is a way to use system font settings on iOS WITHOUT a per-site-user-manually-sets-each-time setting. - See https://github.com/csstools/sanitize.css/issues/219 and https://codepen.io/chrislachance/pen/OJpmgrM
clshortfuse
commented
3 years ago Closing the loop on this. Since the discussions last Fall, iOS Safari has shipped a per-site font size setting, so my understanding is that we no longer need an author opt-in.
@cookiecrook It's great that Apple has something, as well as a workaround. But Android is still forced to 16px. I can easily change zoom (page scaling) with the meta viewport (and I do). But PWAs on iOS devices use whatever the system text size is. PWAs installed over Chrome will always use 16px font, regardless of what the system font size is. In practical experience, the concern is the PWAs I write have font size much smaller than users' other apps.
I pester because Chrome team won't move forward on this unless there's a specification (whereas Apple made a proprietary font-size value).
Edit: Sorry, I noticed @litherum closed this. Can we can get an explanation, or some direction as to where to go to help get this implemented?
cookiecrook
commented
2 years ago @clshortfuse wrote:
I pester because Chrome team won't move forward on this unless there's a specification (whereas Apple made a proprietary font-size value).
The end solution was not the old -apple-system value, which is not widely used.
The solution was that Safari added a site-specific font size control that adjusts the font for any web text, regardless of how the author specifies the units.
But Android is still forced to 16px.
Any browser can add a font size controller to the UI. No additional spec work needed.
cookiecrook
commented
2 years ago @chrislachance wrote:
There is a way to use system font settings on iOS WITHOUT a per-site-user-manually-sets-each-time setting
To clarify, it's not "each time" but "once per site/domain" which turns out to be much more usable than increasing the font size for every site or app...
Most web sites (and even some native iOS apps) are not coded to render well with extra large text, so the native setting can now be applied on an app-by-app basis. This is better received because users don't have to reduce their system font size just to use one poorly coded app.
Likewise, Safari's site-specific control allows low vision users to set the most comfortable font size that works on that site, without worrying about breaking Safari's rendering of the rest of the Web.
clshortfuse
commented
2 years ago The solution was that Safari added a site-specific font size control that adjusts the font for any web text, regardless of how the author specifies the units.
That doesn't work on PWAs though. Personally, I only write Web Apps (PWAs) for businesses so nothing the "full browser" experience provides helps. So you still have to use -apple-system-body if you want proper accessibility support in Web Apps. Right now I'm using that for my users that need larger fonts. The moment the Web App opens, it's automatic and there's nothing more needed.
As for those on Android, I modify the font-size on <html>. It has to be configure manually, and I've even had to add the ability to remotely configure the user's font-size because forcing them to navigating at 16px font-size to enable said options in a custom UI was too stressful for some users.
cookiecrook
commented
2 years ago That doesn't work on PWAs though.
I don’t think that’s a CSS problem. Any browser (including a PWA wrapper web view) can add a font size controller.
iOS includes a feature named "dynamic type" where users can increase the text size all across the OS. This is controlled by a slider in the system Settings app:
A similar feature exists on Windows. Here's a screenshot from the Windows 10 settings app:
In the iOS case, and in the Windows case too from what I can tell, this setting is applied all across the OS, but isn't applied inside content drawn by the browser. In Safari's case, this is because changing text sizes often breaks webpage layout. (Safari has a related feature called "make text bigger" that can bump up the font size on a page regardless of author opt-in, but that setting is per-site, not global.)
We've exposed this feature in Safari by using some non-standard values to the
fontproperty, and we've evangelized this multiple times to developers. However, this feature is probably something that belongs on the Web Platform, rather than being a nonstandard extension.