- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Jan 2025 19:40:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-fonts][css-values][css-viewport] UAs inconsistent in how OS font settings affect the default font-size `medium` ``, and agreed to the following: * `RESOLVED: have the unit (a scaled default font size) and the env() (a scale factor)` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> dgrogan: this is about authros needing access ot the OS default font size<br> <TabAtkins> dgrogan: they can do it today but it's hacky, should have more standardized way<br> <TabAtkins> dgrogan: have talked aobu thtis a few times<br> <TabAtkins> dgrogan: settled on either an env() or a new unit<br> <TabAtkins> dgrogan: I think new unit has some good arguments for it. A few abbrevs suggested in the issue<br> <TabAtkins> dgrogan: we also talked to some authors. they're fine with the new unit, but also interested in having something that's exposed as a %, so they can apply it to the zoom property or text-size-adjust<br> <TabAtkins> dgrogan: so in last discussion, proposal in the issue is both.<br> <TabAtkins> dgrogan: env() would expose a scale factor<br> <TabAtkins> iank_: did we want a % or jsut a raw number?<br> <TabAtkins> TabAtkins: we'll want a raw number so it's more usable in calc()<br> <kizu> q+<br> <TabAtkins> dgrogan: yeah, and they can use calc() to turn it into a %<br> <astearns> ack kizu<br> <TabAtkins> kizu: if we have a separate value which is in px, given that in calc we can divide by 1px and get proportional, is that enough that we dont' need an extra unit value?<br> <TabAtkins> dgrogan: you can't do unit division in browsers today<br> <TabAtkins> kizu: you can in Safari, at least<br> <emilio> q+<br> <dbaron> (I think there's ongoing work to do it in Chrome, too.)<br> <TabAtkins> iank_: I think it's still easier on devs to have the value directly, rather than dividing by a magical number to produce the scale factor<br> <TabAtkins> iank_: It's more fragile than just exposing an env() that's 1.5<br> <astearns> ack emilio<br> <TabAtkins> emilio: Exposing a particular size is weird, because there might be different OS font sizes. the common denomatinor is some text scale factor that OSes have.<br> <TabAtkins> TabAtkins: proposal was a unit that gives you the size directly, and a scale factor<br> <TabAtkins> emilio: If the browser already applies a scale, doesn't using the uint double scale<br> <TabAtkins> emilio: on windows you have text-scale factor of 2. browsers interpret that as scaling the whole website, effectivley the device pixel ratio<br> <TabAtkins> emilio: if i give you a size that's 32px, that wouldn't be what you wanted, it's 4x size<br> <TabAtkins> iank_: looking at what windows actuallyd oes<br> <TabAtkins> iank_: i thought there was a factor that just scales text but not the whole thing?<br> <TabAtkins> emilio: we have a *pref* to do that but by default we all interpret the scale as a pixel scale<br> <florian> q+<br> <TabAtkins> iank_: at minimum we do seem to need the env(). we can optionally offer the unit.<br> <TabAtkins> q+<br> <astearns> ack florian<br> <TabAtkins> florian: i'm not sure that works, i think you need that *and* an opt out<br> <TabAtkins> florian: to say "dont' double the dpx of my site" so then the unit is useful<br> <TabAtkins> florian: otherwise you don't need to know the font size is doubled, becuase the 'medium' value is actually already correct<br> <TabAtkins> iank_: we do have an opt out on mobile, initial-scale-factor in mobile viewport<br> <TabAtkins> iank_: don't think we do it on Mac because settings are slightly different<br> <TabAtkins> iank_: maybe we just file a separate issue for a window opt out<br> <TabAtkins> emilio: i don't think mac has a global text scale<br> <TabAtkins> iank_: it does, but there's two toggles, one scales text the other is a global scale<br> <TabAtkins> iank_: you can probe this value on mobile, where people care a lot. it doens't matter quite as much on desktop, but not sure if people can probe for it<br> <TabAtkins> iank_: we'd hook that pref into this<br> <TabAtkins> iank_: we're not currnetly using that pref at all<br> <TabAtkins> iank_: so the question is do we need an opt out on windows and linux?<br> <TabAtkins> astearns: can we close off the discussion of this extra functionality?<br> <TabAtkins> emilio: but if we do this scaling, the scale factor for env() is always 1.<br> <astearns> ack TabAtkins<br> <emilio> TabAtkins: given this info, what is the issue actually about if it is the case that we already scale the page based on this factor<br> <emilio> iank_: we don't<br> <emilio> ... most of the time<br> <emilio> ... on mobile<br> <emilio> ... web devs, per browser, they try to find out the boosted text paragraph way<br> <emilio> ... on safari I think they probe the specific font thing<br> <emilio> ... they'd store the value and boost their text<br> <emilio> q+<br> <emilio> ... I don't necessarily want to boost the whole text<br> <emilio> TabAtkins: so the page is not fully scaled, but sometimes it is<br> <emilio> iank_: for us on android this toggle would do nothing<br> <emilio> ... it's very difficult<br> <emilio> ... so most sites disable the text auto-sizer<br> <emilio> ... they know how to boost and how much<br> <emilio> ... and they want this value and apply it fine-grained<br> <emilio> ... so this is why we want to expose this as an env()<br> <emilio> ... there's a good explanation on the thread<br> <emilio> TabAtkins: with the information that a lot of time fully scaling the page, but in the times we're fully scaling the page it'd be 1<br> <emilio> iank_: then there's the question of whether we want to have an opt out on windows<br> <florian> q+<br> <emilio> ... would need more research<br> <emilio> ... but that is a separate issue<br> <astearns> ack emilio<br> <TabAtkins> emilio: isn't the main issue that you do nothing with this on android?<br> <TabAtkins> iank_: boosting the page wholesale isn't usually what devs want<br> <TabAtkins> iank_: users want their text boosted, but not in a way that breaks the page<br> <argyle> q+<br> <TabAtkins> iank_: devs want to do the right thing a11y-wise, but boosting the whoel page or using our text auto-sizer heuristics aren't good<br> <TabAtkins> emilio: we do effectively zoom-to-page, changing the dpr<br> <TabAtkins> emilio: a lot of websites taht don't think about it actually get the right behavior<br> <TabAtkins> emilio: impossible to tell if they're on a high-dpr small screen or low-dpr big screen<br> <TabAtkins> iank_: yeah on desktop it's less of an issue since ther'es more real estate, but on mobile you want to be careful with limited space<br> <TabAtkins> emilio: yeah, don't want a mobile site with only half the nromal pixels<br> <TabAtkins> iank_: so this is why devs turn off text autosizing, but they do want to do the right thing for users<br> <florian> q- later<br> <TabAtkins> emilio: i haven't seen much bugs filed from our users against the full-page resizing, but i understand ti<br> <TabAtkins> emilio: even if we expose the scale factor i'd like some opt-in from the page<br> <TabAtkins> emilio: scaling the page when the web author hasn't put in any thought is generally better behavior<br> <TabAtkins> iank_: no<br> <TabAtkins> emilio: yes<br> <TabAtkins> iank_: no<br> <astearns> ack argyle<br> <TabAtkins> argyle: most common case for me is a chat app on a mobile device<br> <joshtumath> q+<br> <TabAtkins> argyle: you want the font-size boosted to max for readability, but not touch areas, or margin, or padding, etc<br> <TabAtkins> argyle: i see both young and old massively boosting their font size for chats, and i'd like my site to read as easily<br> <astearns> ack dbaron<br> <Zakim> dbaron, you wanted to comment on text autosizing<br> <TabAtkins> dbaron: there were refs to turning off text autosizing<br> <TabAtkins> dbaron: it exists int he first place to make pages designed for desktop sizes usable on mobile<br> <TabAtkins> dbaron: it exists in that context, ot basically say when you have a block of text, mobile user will want to pan in to read it, and you want to avoid them hving to then pan side to side to read it<br> <TabAtkins> dbaron: and that notion is tied to the system preference, which is why it can be used to detect the system pref sometimes<br> <TabAtkins> dbaron: but i don't think text autosizing is really designed for mobile-design cases<br> <TabAtkins> iank_: yup<br> <astearns> ack florian<br> <TabAtkins> florian: i think ideally what Adam is talking aobut should work ideally, but we're not in ideal world<br> <TabAtkins> florian: lot of sites would break if you just scale text<br> <TabAtkins> florian: web is in theory capable of doing this, but many sites not designed for it<br> <TabAtkins> florian: so maybe just don't do anything and expose the "good" scale factor<br> <TabAtkins> florian: when authors want to do the right thing i think giving that info is the right thing, but not all will think about it<br> <TabAtkins> iank_: yeah, on mobile zooming or not is a UA decision<br> <TabAtkins> florian: yeah, can decide to zoom to try and make the right choice for users by default.<br> <TabAtkins> iank_: yeah, there's way too many sites that'll, say, set an explicit height on something - you boost the text and it gets clipped<br> <TabAtkins> florian: so it seems that browsers can zoom sometimes, and if you want to do better you need to opt out.<br> <TabAtkins> florian: if you're opting out, maybe opt out of both zoom and text size, give an env() with the font sacle<br> <TabAtkins> florian: or might want to just opt out of zoom, but take the font scaling automatically<br> <TabAtkins> florian: so having a two way opt out which is (1) don't zoom the page, and (2) do or don't change the root font size, but tell me in an env()<br> <TabAtkins> florian: I think that's tehe complete solution<br> <TabAtkins> iank_: yes, i think we expose the environment variable, adn provide a meta viewport to opt into the zoom behaviors<br> <TabAtkins> florian: unsure why can't adjust the 'em' size by default...<br> <TabAtkins> iank_: so many people using libraries, not sure it's actually common to fully accommodate this<br> <astearns> ack joshtumath<br> <TabAtkins> joshtumath: just wanted to thank people for bringing this up<br> <TabAtkins> joshtumath: bringing this back to the original prompt<br> <TabAtkins> joshtumath: in BBC we have webviews and apps, there's no means of saying in the browser UI to adjust the font size<br> <TabAtkins> joshtumath: so authors have to do it<br> <TabAtkins> joshtumath: the meta viewport values would handle that<br> <TabAtkins> joshtumath: we want the ability to say "yes we've thought about it, scale the page", etc<br> <TabAtkins> joshtumath: want rems to scale by user font size, but not px, etc<br> <emilio> q+<br> <TabAtkins> astearns: do we resolve on the unit+env() now? or push back to the meta-viewport discussion?<br> <TabAtkins> astearns: i'm inclined to decide it now<br> <astearns> ack emilio<br> <TabAtkins> florian: yes, while there are cases where things are full zoomed (and scale factor would be 1) and others where it's not<br> <TabAtkins> emilio: i think i'm okay with the scale factor<br> <TabAtkins> emilio: adding the font unit seems like a lot of overhead<br> <TabAtkins> q+<br> <TabAtkins> emilio: seems like there are a lot of issues - setting being respected on browsers, in webviews...<br> <TabAtkins> emilio: i'm okay with exposing one scale factor, exposing a whole set of font units seems like a lot<br> <joshtumath> q+<br> <TabAtkins> iank_: our opinion is env() is needed, unit is nice to have<br> <TabAtkins> emilio: so i think doing jsut an env() for now and unit later<br> <astearns> ack TabAtkins<br> <emilio> TabAtkins: the big reason to supply one unit was brought up was to be able to use it in media query<br> <emilio> ... because that's intended to be a common case to use in media queries or what not<br> <dbaron> Is it like an em or like a rem?<br> <emilio> TabAtkins: one or another, I dunno<br> <astearns> ack joshtumath<br> <TabAtkins> dbaron: it's relevant question, ems are scaled again and again<br> <emilio> dbaron: relevant because one multiplies over and over<br> <TabAtkins> TabAtkins: sounds like a scaled rem then<br> <TabAtkins> joshtumath: yeah, ask is mostly for a rem<br> <emilio> q+<br> <TabAtkins> joshtumath: when trying to hotfix this with a proprietary apply font property, setting it on the root meant that MQs still didn't work right.<br> <TabAtkins> joshtumath: thus the need for the unit to always exist, not be dependen ton a property<br> <astearns> ack emilio<br> <TabAtkins> emilio: so a bit confused, do we really want a rem?<br> <TabAtkins> emilio: or just relative to the default font size? (not changed by the actual root font-size)<br> <TabAtkins> dbaron: I think the latter, yes<br> <fantasai> pem = preferred font size em<br> <joshtumath> +1<br> <TabAtkins> astearns: so let's have a proposed resolution to have the unit (a scaled default font size) and the env() (a scale factor)<br> <TabAtkins> RESOLVED: have the unit (a scaled default font size) and the env() (a scale factor)<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-2625414100 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 January 2025 19:40:25 UTC