- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Jun 2019 18:16:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Dynamic text size`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Dynamic text size<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/3708<br> <TabAtkins> AmeliaBR: Want to bea ble to respect user's font sizes, espeically on mobile, without arbitrarily overriding website styles in ways that break pages<br> <TabAtkins> AmeliaBR: Want good pages to be able to opt into user's prefs at the OS level.<br> <TabAtkins> AmeliaBR: I brought it up becaus ein the issue' slong discussion there were some straightforward proposals.<br> <TabAtkins> AmeliaBR: One was a new "system-font" keyword (for 'font' shorthand)<br> <TabAtkins> AmeliaBR: WebKit has a keyword for that<br> <TabAtkins> AmeliaBR: Suggestino is to standardize that<br> <TabAtkins> AmeliaBR: Already have font-family keyword that is system-ui, waiting for FF impl, but in two browsers and in spec<br> <TabAtkins> AmeliaBR: Diff for 'font' keyword is you'd also get defautl sizing<br> <TabAtkins> AmeliaBR: Second, trickier aspect is what if an author wants to opt into the user's font size without getting the system font.<br> <TabAtkins> AmeliaBR: My argument is taht's what "medium" was supposed to be.<br> <TabAtkins> AmeliaBR: Might get messy, maybe we can talk about that.<br> <TabAtkins> myles_: Some context:<br> <TabAtkins> myles_: browsers have 11k ways to adjust text sizes<br> <TabAtkins> myles_: All area balance between making text readable and trying to not break layout<br> <TabAtkins> myles_: Having a website opt in and say "I know this part of the page will respond well" won't fix every site, but will at least let us resize taht part more freely.<br> <TabAtkins> myles_: General request is really important for a11y.<br> <TabAtkins> myles_: (and just that people like to change their font size)<br> <TabAtkins> myles_: Every OS has this, ebook readers too.<br> <TabAtkins> myles_: So I'm just hoping for some way for a website to say "for this part of the page, go hogwild"<br> <TabAtkins> myles_: We have a non-standard prefixed mechanism for this<br> <TabAtkins> myles_: Would be cool to resolve on that, but we're not married to it<br> <TabAtkins> myles_: ANother idea is to use env()<br> <TabAtkins> myles_: Interesting on iOS which lets you change both size *and* weight<br> <TabAtkins> myles_: I don't wanna prescribe any specific solutions, but would be cool to come up with something for this.<br> <AmeliaBR> s/talk about that/talk about that after agreeing on the shorthand keyword/<br> <TabAtkins> myles_: OUr existing solution is a 'font' keyword<br> <TabAtkins> myles_: You can say "font: -apple-system-body"<br> <AmeliaBR> Proposal is to add a `system-body` keyword for the font shorthand. Sets the font-family and size together.<br> <TabAtkins> myles_: It'll resolve to a specific size, so if you want your page to react fluidly as the user slides their font-size slider, you put that value on the root element and let the inherited style work correctly<br> <TabAtkins> koji: I don't have a preference for solution, but I'm hearing the request for -apple-system-body in Blink<br> <TabAtkins> koji: Would be great to standardize<br> <TabAtkins> dbaron: Presumably there's some default size for this keyword.<br> <TabAtkins> dbaron: What % of users have it at this default size?<br> <TabAtkins> dbaron: My concern is that if it's over, say, 75% or more, pages will likely still not work if it changes.<br> <TabAtkins> myles_: Dunno<br> <chris> q+<br> <TabAtkins> AmeliaBR: The whole point of this is to not change anything by default<br> <TabAtkins> AmeliaBR: Webpages have to opt into it<br> <TabAtkins> AmeliaBR: So your concern is that they might opt in thinkiing they're getting a standared default, and not realize it's adjustable?<br> <TabAtkins> dbaron: My concern is that things that don't get tested get broken. If it's only true for a small %, it won't get tested, and even if original design got it right, someone will come along later and make it break for a non-default size.<br> <TabAtkins> dbaron: Just like before we made px be a 96:1 ratio with in. Users with a different ratio, only in Firefox and IE, saw broken websites.<br> <TabAtkins> myles_: Can't answer directly, but can offer some info<br> <TabAtkins> myles_: In our xp, this isn't just a11y. Many users change just because they like bigger text sizes<br> <dbaron> TabAtkins: it sounds like from your suggestion from using -apple--ystem-body on the root and then using rems or inheritance<br> <dbaron> ... does address Amelia's request to just get the font size people want?<br> <dbaron> myles_: yes<br> <dbaron> TabAtkins: it sounds like from your response to david that there's a decent percentagechanging to a non-default value?<br> <dbaron> myles_: yes<br> <TabAtkins> jensimmons: Is what's being proposed only affecting font-size? Or is there an easy way to cascade that measurement into layout?<br> <TabAtkins> jensimmons: Is it diff from just using 'em's, etc?<br> <astearns> q+<br> <TabAtkins> myles_: This should be a way of seting font-size like any other way of doing so. Does that answer your question?<br> <AmeliaBR> s/--ystem/-system/<br> <TabAtkins> jensimmons: There are many websites that don't do things right, we have to consider them bc they're majority. But this is an issue been incredeibly important to front-end designers/teachers: make a webpage work when people choose their font size.<br> <TabAtkins> jensimmons: These days the only thing left ot understnad is how to zoom on desktop<br> <TabAtkins> jensimmons: Be3st practice has change dmany times over the years.<br> <TabAtkins> jensimmons: A bit of tail-chasing, browsers trying to chase badly-writtens ites, and good sites chasing browsers, and round and round.<br> <TabAtkins> jensimmons: And bc info about best practice ages, people dont' realize it's old; like people still say "set font-size on root to 10px and use 'rem'"<br> <TabAtkins> jensimmons: So this comes down to, have an easy way to let users change font size and have an easy way to adapt to it.<br> <TabAtkins> jensimmons: So I just want this to fit into that evolutionary convo.<br> <TabAtkins> jensimmons: Rather than YetAnotherWayToDoIt<br> <TabAtkins> (YAWTDI)<br> <TabAtkins> myles_: agree 100%<br> <TabAtkins> myles_: My intention isn't to make a new blessed way to design responsive websites<br> <florian> q?<br> <florian> q+<br> <florian> q-<br> <TabAtkins> myles_: More allow authors to annotate their source with some info we don't already have, and that annotation is "this part of the page works well when font-size changes"<br> <TabAtkins> florian: I think this new proposal ahs a chance of breaking the cycle, precisely because this setting is used by a large number of people. It's always existed, but tended to b eused by few.<br> <jensimmons> q?<br> <TabAtkins> florian: Like dbaron said, when too few people use it, things break.<br> <TabAtkins> florian: But because this is used by many, there's a chance it'll stay viable, rather than being poisoned by maintenance.<br> <TabAtkins> jensimmons: THe idea we should take the pref setting and give it to webdevs to use, I'm definitely for it.<br> <astearns> ack chris<br> <heycam> q+ to ask why is this -apply-system-body font size not the default font size applied in the page?<br> <TabAtkins> chris: I noticed in the thread that someone suggested there should be a property that is system-font-size * browser font scale<br> <jensimmons> heycam: +1<br> <TabAtkins> chris: I'm not opposed to a new generic font family, but if people are using that purely to get at the size, that seems more robust to me.<br> <chris> "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. "<br> <TabAtkins> chris: To get the size directyl, rather than usign the whole font just to get the size<br> <jensimmons> (I mean +1 to what heycam added to the question que… not that he said “+1”)<br> <TabAtkins> AmeliaBR: There's content out now that's UA-dependent, trying to recreate the system body font.<br> <TabAtkins> AmeliaBR: (which I find annoying, as I don't like Window's system font...)<br> <TabAtkins> AmeliaBR: But a keyword would b esmarter than the website trying to *guess* that I want Seguo UI.<br> <TabAtkins> AmeliaBR: So I think there's a demand for combined, but we should also do apart. But Tab did say that if we have the font keyword on root, we can just use 'rem's.<br> <TabAtkins> AmeliaBR: But I would prefer "font-size: medium" to do actually that, but...<br> <TabAtkins> chris: You ran some tests; we saw that browser didn't do that.<br> <TabAtkins> myles_: WE've tried to make "medium" reflect preferred size. It breaks too much, can't do it.<br> <TabAtkins> astearns: Why is this a keyword on 'font' rather than a keyword for font-size?<br> <TabAtkins> myles_: There's a collection of 'font' keywords.<br> <TabAtkins> myles_: This one means "this is the size that best fits apple body text"<br> <TabAtkins> myles_: Now that we have system-ui generic font family distinct from that, I think the use-case is [...?]<br> <TabAtkins> astearns: So system-ui is on font-family, not 'font'?<br> <TabAtkins> myles_: Yes.<br> <astearns> ack astearns<br> <jensimmons> q+<br> <chris> so I guess it sets the line spacing too<br> <astearns> ack heycam<br> <Zakim> heycam, you wanted to ask why is this -apply-system-body font size not the default font size applied in the page?<br> <TabAtkins> heycam: You answered "Why is this just not the default". What specifically did you try? Did you try switching "medium" and leaving th einitial font-size to 16px, di dyou try changing initial and leaving "medium", or?<br> <TabAtkins> myles_: The latter<br> <TabAtkins> heycam: What actual font-family is set by this? Same initial value that kinda depends on lang and so on? Or always serif?<br> <TabAtkins> myles_: The system font, "San Francisco" on Apple<br> <TabAtkins> TabAtkins: So it's the system-ui font?<br> <TabAtkins> myles_: Yes<br> <astearns> ack jensimmons<br> <TabAtkins> AmeliaBR: system-ui is a new generic, an alternative to 'serif' or 'sans-serif'<br> <TabAtkins> jensimmons: If your CSS you use to react to diff prefs is different on mobile than desktop, that's bad. Is it?<br> <TabAtkins> myles_: Android and iOS both have this setting, windows desktop has this setting. Dont think it would differ.<br> <TabAtkins> jensimmons: [minuting failure]<br> <TabAtkins> jensimmons: If this is something you're supposed to use, but it only works in some browsers, that's a problem.<br> <TabAtkins> AmeliaBR: So your concern is that browsers with an in-browser font-size option, the system font being pulled from outside the browser wouldn't match?<br> <TabAtkins> myles_: Does "work" mean that it draws from the OS? That can be done on eveyr platform. Or does it mean some devices on a platform will have one value and other devices on that platform will have others?<br> <TabAtkins> AmeliaBR: So should the value come from browser, or browser+OS, or what?<br> <TabAtkins> TabAtkins: I don't think there's any reasonabl euse-case for "OS size" different from "browser-provided default size"<br> <TabAtkins> chris: I wasn't suggesting two vars, I was suggesting a single thing from multiplying those together.<br> <TabAtkins> myles_: So I think we have consensus for a font-size env()?<br> <TabAtkins> myles_: Also, since we expose weight, do we want an env() for weight?<br> <TabAtkins> TabAtkins: Sounds okay, but slightly concerned due to dbaron's concern about small usage.<br> <AmeliaBR> So, to get the effect of the -apple-system-body keyword would be `font: env(preferred-font-size) system-ui;`<br> <TabAtkins> emilio: Firefox's font settings are per-lang, so I'm not sure how to distill that to an env() value<br> <TabAtkins> And to get the opposite would be `font: -apple-system-body; font-family: foo;`<br> <TabAtkins> astearns: I don't like the default weight; the page would lose the the distinction between bold and not.<br> <TabAtkins> myles_: Yeah, they're aksing for that.<br> <TabAtkins> astearns: They're asking for it in system UI, which doesn't use much bold. Not necessarily in web content.<br> <TabAtkins> TabAtkins: Does Apple system ui tend to use bold to distinguish stuff, such that the default weight would lose information?<br> <TabAtkins> myles_: There's some, but it's rare, so not much info is lost.<br> <TabAtkins> astearns: So emilio, if you had an env(), you'd have to pick which size to use based on lang, etc.<br> <TabAtkins> astearns: But you have to make the same decision for the keyword, right?<br> <TabAtkins> emilio: Different. You'd have the element language, you'd apply the generic family.<br> <TabAtkins> TabAtkins: So you're saying that the font keyword, being resolved on the element, can be different per-element based on lang? But the env(), which should be global, can't do that?<br> <TabAtkins> emilio: Yes.<br> <TabAtkins> AmeliaBR: "medium" on Chrome and Firefox currently resolves to user font size.<br> <koji> q+<br> <TabAtkins> emilio: Right, so I guess an env() font-size for that would be okay.<br> <astearns> ack koji<br> <TabAtkins> koji: I'm confused. THi sis about exposign system font size setting, right?<br> <dbaron> s/right/not user's setting in browsers, right/<br> <TabAtkins> koji: But windows/mac/etc all expose only a single value<br> <dbaron> emilio: That makes sense.<br> <TabAtkins> AmeliaBR: The idea is that the exposed variable is the setting in the browser, if they capture that, or OS otherwise<br> <TabAtkins> fantasai: A problem with "medium" is that it can't reflect user setting<br> <TabAtkins> TabAtkins: Myles did tests for the *initial value* being user's setting, and that broke stuff. But Chrome/Firefox reflect "medium" being the user's setting.<br> <TabAtkins> AmeliaBR: But that's the same thing, as "medium" is the initial value.<br> <TabAtkins> myles_: So I think this topic is an investigation, we're not going to finish right now.<br> <TabAtkins> astearns: But I think the room has a general intent that this is a good idea.<br> <TabAtkins> AmeliaBR: If people have data for what % of users change their default font size, or how much breakage is observed when things change, this would be useful info in the issue.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3708#issuecomment-499608647 using your GitHub account
Received on Thursday, 6 June 2019 18:16:55 UTC