- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Dec 2024 18:04:28 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-fonts][css-viewport] UAs inconsistent in how OS font settings affect the default font-size `medium` ``. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> joshtumath: back in 2019, issue 3708 the WG discussed having support for "dynamic type" on iOS<br> <TabAtkins> joshtumath: in OS settings changing the font size and ahving it reflected in the page<br> <TabAtkins> joshtumath: resolution to have some way to do true font sizes<br> <TabAtkins> joshtumath: but a ta f2f there was a comment about general consensus for this done with meta-viewport<br> <TabAtkins> joshtumath: a year later this was closed because Safari added a per-site setting<br> <TabAtkins> joshtumath: so wanted to discuss this again<br> <TabAtkins> joshtumath: at BBC, had some complaints becuase some of our apps use a webview to embed a browser, and there is no controls to change font size in a webview, you have to get that from the OS settings<br> <TabAtkins> joshtumath: but there's no mechanism for that<br> <TabAtkins> joshtumath: would like WG to consider either adopting a meta-viewport tag, or some other mechanism<br> <TabAtkins> q+<br> <astearns> ack TabAtkins<br> <bramus> TabAtkins: at the time it was talked about, did we have the env spec? seems like the correct way to inject this info<br> <TabAtkins> keithamus: last comment was about using env()<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: i'd like to avoid meta-viewport as much as possible for styling, that's not where that info should go<br> <TabAtkins> fantasai: so unless there's a critial reason for it, it shouldn't be a solution we reach for<br> <TabAtkins> fantasai: i think it is reasonable to specify that you want the system default font size<br> <TabAtkins> fantasai: already have keywords for system-ui font, etc<br> <joshtumath> q+<br> <TabAtkins> fantasai: so if we can't reuse 'medium', which seems likely, we can creaete a new keyword<br> <astearns> ack joshtumath<br> <TabAtkins> +1, yeah duh, just a font-size keyword seems right<br> <emilio> q+<br> <TabAtkins> joshtumath: want to amke sure that anywhere we can enable this is reflected into MQs with rem units<br> <TabAtkins> joshtumath: if you change root font-size that's not reflected in MQs<br> <TabAtkins> Ah, good point<br> <keithamus> q+<br> <TabAtkins> joshtumath: if i zoom in, that'll affect MQs<br> <TabAtkins> astearns: is that solveable with CQs rather than MQs?<br> <astearns> ack emilio<br> <TabAtkins> joshtumath: It is, but would be a lot of code changes. Reluctant to use CQs for everything, still plenty of reasons for MQs<br> <TabAtkins> emilio: yeah, MQ point makes this moot...<br> <TabAtkins> emilio: some OS font settings *are* exposed via system fonts. If you set `font: dialog` or whatever, they can have different computed font-sizes depending on OS settings<br> <TabAtkins> q+<br> <astearns> ack keithamus<br> <TabAtkins> keithamus: presumably would want to derive other units - is a keyword applicable, or want a new dimension?<br> <TabAtkins> keithamus: might want to clamp, for example<br> <emilio> q+<br> <astearns> ack TabAtkins<br> <bramus> TabAtkins: i agree. both MQ point and what keith pointed out. Need a resolvable value, not just a keyword. dont car if its env or unit. env seems semantically more appropriate<br> <astearns> ack emilio<br> <fantasai> +1 to resolvable font size<br> <keithamus> q+<br> <TabAtkins> emilio: re previous point, some OSes don't have a unified concpt of default size, there are different sizes for different UI elements<br> <TabAtkins> emilio: Window, perhaps Linux<br> <TabAtkins> emilio: don't know if we want to account for that<br> <astearns> ack keithamus<br> <TabAtkins> keithamus: if it's a dimension we'd need to specify what the resolved value is, or what the fallback is<br> <TabAtkins> keithamus: if we use env(), can you provide a fallback?<br> <bramus> yes<br> <TabAtkins> yes, env() has a fallback<br> <bramus> `env( <custom-ident> <integer [0,∞]>* , <declaration-value>? ) `<br> <TabAtkins> emilio: it does feel a bit weird to have conditionally supported vars like that...<br> <TabAtkins> keithamus: i thouht not all OSes would want to define that value..<br> <TabAtkins> emilio: more that there's potentially multiple values to expose<br> <TabAtkins> TabAtkins: advantage of env() is we can easily supply a family of keywords if we want<br> <bramus> TabAtkins: benefit of env is that we can provide a family of keywords with the same prefix<br> <bkardell_> q?<br> <astearns> ack fantasai<br> <TabAtkins> emilio: yeah, sorry, having a solution would be great, just pointing out complications<br> <TabAtkins> fantasai: clarifying - is this one font-size, or a variety?<br> <TabAtkins> emilio: that was my point, you put it better<br> <TabAtkins> keithamus: what would the variety of font-sizes be?<br> <TabAtkins> astearns: i think if we depend on what OSes/browses are offering in terms of settings<br> <TabAtkins> fantasai: bigger question - what are authors trying to match<br> <TabAtkins> fantasai: definitely paragraph text size, good to match the OS<br> <keithamus> q+<br> <TabAtkins> fantasai: do we need other things as well?<br> <astearns> ack keithamus<br> <TabAtkins> keithamus: good point, there's oftentimes a preference for different sizes basd on fixed-width fonts<br> <TabAtkins> keithamus: in my system settings there's a bunch<br> <TabAtkins> iank_: main use-case here is body/paragraph text, sites are detecting this in the browser today via interseting means<br> <TabAtkins> iank_: related to text-auto-sizing<br> <TabAtkins> iank_: they want to be able to boost paragraph text size for a11y reaons<br> <TabAtkins> astearns: hearing we'd like to pursue this as an env() that resolves to a length<br> <bramus> TabAtkins: that was answered by MQs and math fns<br> <TabAtkins> fantasai: why env() not a font keyword?<br> <TabAtkins> iank_: often the case you'd want to change the height of a box/etc<br> <TabAtkins> fantasai: but you could set it on root and use the values<br> <bramus> TabAtkins: not accessible in rems and MQs.<br> <TabAtkins> fantasai: we could make MQs respond to user's real default size<br> <bramus> TabAtkins: would be different feature<br> <TabAtkins> astearns: we're over time, take it back to 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/10674#issuecomment-2536724545 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 December 2024 18:04:29 UTC