- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 20:25:36 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-fonts-5] <meta text-scale> limits`, and agreed to the following: * `RESOLVED: Add NUMBERpx to values of text-scale meta, deprecate 'scale' keyword (and make it optional for conformance).` <details><summary>The full IRC log of that discussion</summary> <emilio> fantasai: one of the issues raised internally was that a lot of times authors think they've designed the page to scale but on iOS there's a scale for dynamic type that has a default and some bigger/smaller sizes, but also an extended scale when you turn on a11y settings that the author did not expected<br> <emilio> ... so we'd like the meta to not be a binary switch and include how big you can handle your font<br> <emilio> ... so that they can say "I can handle up to 80px" or so<br> <dgrogan> q+<br> <emilio> ... and the engine can use other methods to zoom past that if necessary<br> <Rossen> ack dgrogan<br> <emilio> dgrogan: makes sense, I understand the problem<br> <emilio> ... two things I've written in the issue 5 mins ago<br> <emilio> ... are we planning to do this in addition to the keywords?<br> <emilio> fantasai: I think it'd replace the keywords<br> <emilio> ... because otherwise the author will just claim to scale infinitely<br> <emilio> dgrogan: one issue is that we're shipping that already, can't remove that<br> <emilio> ... the other thing we've talked about is that when the page has this meta specified we'd simulate the font<br> <emilio> ... to a random value they should handle<br> <emilio> ... but yeah we can't unship this<br> <emilio> fantasai: I'd suggest not ripping it out because it's doing something useful, but pushing it to devrel once we have the new syntax<br> <emilio> ... so that we can mark it as deprecated<br> <emilio> ... and we wouldn't ship that<br> <emilio> ... which would allow to eventually move to the new syntax<br> <emilio> ... there are other concerns about privacy that we haven't figured out yet<br> <emilio> ... but I hope we can get to that<br> <emilio> dgrogan: maybe we can do that in the future and drop it? I can't make promises<br> <emilio> fantasai: we'd have to see what the compat data is<br> <emilio> ... but if we introduce this we can introduce pressure to switch over<br> <emilio> dgrogan: yeah and we can accept the value and see where they are<br> <emilio> ... so that's a future bridge we'd have to cross<br> <emilio> ... the other question is, in the OP what do you mean by default size?<br> <emilio> fantasai: medium<br> <emilio> dgrogan: cool, I think I'm good then<br> <emilio> Rossen: so back to your proposal fantasai?<br> <emilio> fantasai: The question is which lengths would be valid<br> <emilio> ... do we want just pixels there?<br> <dgrogan> +1 pixels only<br> <emilio> emilio: I think pixels is fine<br> <Rossen> q?<br> <emilio> emilio: at the end of the day you're comparing against the medium font which computes to pixels<br> <florian> q+<br> <emilio> florian: there are use cases to maybe specify a viewport-relative length?<br> <florian> q-<br> <emilio> ... if my font is huge but my viewport is huge too it might be fine<br> <miriam> q+<br> <emilio> q+<br> <emilio> ack miriam<br> <emilio> miriam: I think it's important to understand that there's no way to distinguish between small viewport and zoomed viewport<br> <emilio> emilio: but I think it's fine, because the zoom size will also scale<br> <Rossen> ack miriam<br> <Rossen> ack emilio<br> <florian> q+<br> <dbaron> I'd say it's *desirable* that they can't be distinguished because it reduces the number of degrees of variation that need to be *tested*.<br> <fantasai> emilio: I understand use case of 12vh clamped or something<br> <fantasai> emilio: But seems complicated. Need to recheck on resize, etc.<br> <fantasai> emilio: so I think the MVP would just be pixels<br> <fantasai> emilio: Good enough, I support up to font-size: 80px on any viewport<br> <fantasai> emilio: and if we need to expand it, could be done. But would be annoying<br> <fantasai> emilio: Like if rotating your device changes how the page is zoomed<br> <Rossen> ack florian<br> <emilio> florian: It's simpler to implement and reason about with pixel values<br> <emilio> ... but a bunch of responsive designs, idk, up to how many pixels can you handle? it depends on how big is the viewport<br> <emilio> ... e.g. 10vw<br> <emilio> ... so if the viewport is tiny don't make the font huge and so on<br> <emilio> ... and there's no value that would be correct<br> <miriam> +1<br> <emilio> ... so authors of responsive pages won't be able to give you a meaningful size<br> <astearns> ack fantasai<br> <emilio> fantasai: that's true but also as an author this is just the input we're feeding to the author<br> <emilio> ... they can use calc() to get whatever output they want<br> <emilio> ... so they have some complicated font-size for the root with a complicated expression they can clamp it to vh<br> <emilio> ... we don't need the meta tag to have that functionality<br> <emilio> florian: I agree but it's about how big they've tested, and about informing the browser of when the site would break<br> <emilio> fantasai: the site can clamp in the stylesheet if needed<br> <emilio> ... what would the browser do with that information?<br> <emilio> florian: it'd clamp the size<br> <emilio> fantasai: if you're going through that effort in order to get the font clamped, you could do that already<br> <fantasai> emilio: plus having the unclamped value in MQ is potentially useful<br> <emilio> florian: with the viewport meta we let authors the width they can handle<br> <emilio> fantasai: the viewport scales the whole page not just the width<br> <emilio> ... [missed]<br> <emilio> ... but if you're going through the trouble to make the font not go over the size<br> <emilio> florian: they're not going through the trouble of anything, just informing the browser<br> <emilio> ... I think having v* units in addition to pixel<br> <emilio> ... would be useful<br> <emilio> ... it's not broken to have just pixels, just insufficiently useful<br> <emilio> Rossen: what if we started with pixels and add viewport units later?<br> <emilio> florian: sure<br> <emilio> +1<br> <emilio> florian: I think the risk is that either (1) authors will test as you expect their size until certain screen width<br> <emilio> ... but if the page is on a different screen width they'll clamp sizes at widths that they can't handle<br> <emilio> ... or (2) they'll claim they support up to 24px to prevent it<br> <emilio> ... the later is a bit harder<br> <emilio> fantasai: I don't think providing viewport units fix this tho<br> <iank_> you could imaging a media query type syntax for < 1024px i support this font-size.<br> <emilio> Rossen: we're going a bit in circles<br> <fantasai> fantasai: if the author didn't think about that case, they didn't think about it. Providing viewport units won't change that.<br> <miriam> this would be helped a lot with good dev tools<br> <emilio> iank_: you could imaging a media query type syntax for < 1024px i support this font-size<br> <emilio> (srcset-like?)<br> <fantasai> PROPOSED: Add NUMBERpx to values of text-scape meta, deprecate 'scale' keyword (and make it optional for conformance).<br> <emilio> emilio: or just supporting the media attribute on the meta tag?<br> <miriam> authors right now handle `medium` by assuming it's just always `16px` :(<br> <fantasai> s/scape/scale/<br> <dgrogan> +1<br> <fantasai> PROPOSED: Add NUMBERpx to values of text-scale meta, deprecate 'scale' keyword (and make it optional for conformance).<br> <emilio> RESOLVED: Add NUMBERpx to values of text-scale meta, deprecate 'scale' keyword (and make it optional for conformance).<br> <fantasai> emilio: What about supporting the media attribute on the <meta>?<br> <fantasai> florian: It's nice in CSS that you have different units in CSS<br> <fantasai> florian: can approximate it with mq but not nice<br> <fantasai> emilio: A lot of layouts have breakpoints<br> <fantasai> emilio: could have both<br> <fantasai> lea: need both, mq is for dramatic changes and units are for interpolation<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13557#issuecomment-4180298039 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 April 2026 20:25:37 UTC