- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 13 Nov 2025 01:05:56 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-fonts-5] Text Fitting: Shrinking and Growing`, and agreed to the following: * `RESOLVED: use text-fit for now` <details><summary>The full IRC log of that discussion</summary> <astearns> ack tkent<br> <ydaniv> tkent: should we provide a single property? or separate ones?<br> <astearns> q+<br> <ydaniv> ... also will there be a shorthand?<br> <ydaniv> ... [showing slides]<br> <ydaniv> ... a new text-fit property<br> <ydaniv> ... a new text-grow property, and a new text-shrink property<br> <kizu> q+<br> <miriam> q+<br> <ydaniv> astearns: chair hat off, my impression is that the grow version of this feature has the most uses<br> <ydaniv> ... I see uses for shrink, but don't know if it's something authors will use much<br> <iank_> q+<br> <ydaniv> ... would like a fitting feature that grows first, and consider allowing shrinking later, before we box ourselves, and focus on grow<br> <astearns> ack astearns<br> <ydaniv> iank_: we have people that want to use the text shrink specifically<br> <ydaniv> astearns: is taht request documented well? what for?<br> <ydaniv> iank_: they want to contraint an area and reduce things as much as possible<br> <iank_> q-<br> <astearns> ack kizu<br> <ydaniv> kizu: common cases are when have a number as big as possible and then shrink it<br> <ydaniv> ... initial problem can be cumbersome, I think text-fit is the base option here<br> <adamargyle> +1<br> <emilio> q+ to ask how would shrinking interact with stuff like minimum-font-size and other accessibility settings<br> <ydaniv> ... if we have either grow or shrink ...<br> <ydaniv> ... having a single property helps here to simplify here<br> <ydaniv> ... and later allow grow/shrink for more usecases<br> <ydaniv> TabAtkins: I want to understand, when you allow just shrink or grow ...<br> <ydaniv> kizu: whatever font size you have to specify and then it's either growing or shrinking<br> <florian> q+<br> <ydaniv> ... this allows you to say how much you want it to grow or shrink<br> <astearns> ack miriam<br> <ydaniv> +1 to kizu<br> <ydaniv> miriam: sounds to me like use cases are ...<br> <ydaniv> ... I like the simple text fit option more<br> <ydaniv> ... concerned about a11y issues, is there another issue for that?<br> <ydaniv> kizu: there is one, not mentioned here<br> <ydaniv> ... we had concerns about some of the [missed]<br> <ydaniv> ... mostly related to drawing, if it's unlimited you may need to zoom your text by 200% or more<br> <ydaniv> ... with browser zoom will allow you to grow a lot, but have a limitation of viewport<br> <astearns> +1 to worries with shrink accessibility<br> <ydaniv> miriam: I worry about shrink option, if it is able to continue shrinking, would prefer if there was a baseline, and only have a top clamp and bottom open ended<br> <ydaniv> ... so agree with astearns<br> <ydaniv> astearns: kizu mentioned you have more slides?<br> <emilio> ack emilio<br> <Zakim> emilio, you wanted to ask how would shrinking interact with stuff like minimum-font-size and other accessibility settings<br> <ydaniv> tkent: yes<br> <ydaniv> emilio: glad you said that, the whole shrinking thing sounds bad<br> <tkent> https://docs.google.com/presentation/d/1ECs9qBS6yJiGy8aYbJ6vz3ph77mI1mnUgWqcBqFNv7k/edit?usp=sharing<br> <ydaniv> ... not so much as an a11y issue, but could shrink the text down to something that can't be used<br> <ydaniv> ... so +1 to start simple<br> <ydaniv> miriam: don't think we should dismiss the rest, there's no guarantee this will always be used on large text<br> <astearns> ack florian<br> <astearns> ack fantasai<br> <astearns> q+ florian<br> <dholbert> q+<br> <vmpstr> q+<br> <ydaniv> fantasai: are we asking for 1 proeprty? or 2?<br> <ydaniv> astearns: it's the one or the 2<br> <ydaniv> fantasai: I think we should go with the 2, and shorthand them<br> <ydaniv> kizu: wanted to mention that text-fit will allow adjusting spacing and fitting, and will be more extensible<br> <ydaniv> ... very hard to solve if we have multiple properties at the same time<br> <ydaniv> fantasai: one way to work around a11y where people have a muinimum font-size, is to always clamp, with an overide keyword<br> <ydaniv> miriam: it's unreliable, people misuse it<br> <lea> q?<br> <vmpstr> q-<br> <ydaniv> fantasai: would should do flooring the value by default<br> <lea> q+<br> <ydaniv> ... your prefered size is not the smallest one, and you should have a declared starting point<br> <astearns> ack florian<br> <ydaniv> florian: I think we should go with a single property<br> <ydaniv> ... shrinking is possible, but not all possibilites make sense<br> <fantasai> s/misuse it by e.g. setting it to 10px so they have a unit that's 10px/<br> <ydaniv> ... so shows syntax is wrong, if we have a single property it may allow a more sensible combination<br> <ydaniv> ... as for shrinking, useful buy also dangerous<br> <miriam> q+<br> <ydaniv> ... when users try to zoom and grow the text but it doesn't, it's hostile for users<br> <ydaniv> ... we've been talking about font size, but also need to mention letter spacing and others<br> <ydaniv> ... at some point if you reduce letter spacing too much it's not readable<br> <ChrisL> q+<br> <ydaniv> ... let's not give up on shrink too quickly, and focus on the grow one first<br> <ydaniv> astearns: we chair hat on, getting into details here<br> <miriam> q-<br> <ydaniv> ... 3 separate issues here, and Q is growing, would like to scope it to are we using option A or B (1 or 2 properties)<br> <iank_> my worry with only supporting growing is that people will just set `font-size: 0.1px` and grow from there which is sub-optimal<br> <miriam> and a vote for option 'a'<br> <ydaniv> ... and the rest we should discuss separately<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <fantasai> +1 iank_<br> <astearns> ack dholbert<br> <ydaniv> dholbert: thinking about dynamically loading content, the grow feature, may force text to grow too much in size<br> <astearns> ack lea<br> <ydaniv> ... don't have an easy way to avoid<br> <ydaniv> lea: seems useful to have a customsable min and max<br> <ydaniv> ... to control text size is a separate thing<br> <ydaniv> ... regarding shrink/grow, if you can only grow and specify just min size may not be great for a11y<br> <ydaniv> ... also the slides seem to talk about other stuff that are not text<br> <ydaniv> ... have you considered a unit-based approach?<br> <ydaniv> ... when you see designers they sometime control font size, sometimes letter spacing<br> <dholbert> (specifically the scenario I'm imagining is if you have a line of text "AAA BBB" that happens to exactly fit, and then some dynamic change happens [e.g. an image loads] and you have to linewrap "AAA" and "BBB" to two lines; then they'd grow to ~2x their initial size. And that sort of change might be a bit jarring)<br> <ydaniv> ... sometimes it's ok to allow letter spacing grow longer, sometimes not<br> <ydaniv> ... what if we had similar semantics to fr? and you could use it in clamp or minmax<br> <astearns> dholbert: that is exactly the effect that some authors want :)<br> <TabAtkins> q+<br> <astearns> ack ChrisL<br> <ydaniv> ... something along these lines, not well-formed yet<br> <TabAtkins> Issue with that is that it would only allow "consistent" growth/shrink, not per-line<br> <ydaniv> ChrisL: wanted to point out when grow text kerning can change, we shouldn't forget these aspects<br> <astearns> ack fantasai<br> <ChrisL> s/kerning/kerning, tracking and optical size/<br> <ydaniv> fantasai: on the syntax front, if it's option A, you want to be able to relate the limit to multiple operations you're doing<br> <ydaniv> ... so I think the syntax needs some more work to allow it<br> <TabAtkins> There is a lot, but we can't actually search all of them in a reasonable way. That's why, at least at first, basing it on font-size *only* is a reasonable choice. (It's also nearly the only option that is *guaranteed* to work on any font.)<br> <noamr> q+<br> <ydaniv> ... and +1 to be able to set default font-size and adjust from there<br> <ydaniv> astearns: so deciding on one of these options, is that viable?<br> <noamr> q-<br> <ydaniv> kizu: so this is a start<br> <ydaniv> astearns: I think A is better option<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <ydaniv> ... other comments?<br> <ydaniv> lea: would be great to have library that exposes this and we can observe authors' usage<br> <ydaniv> miriam: there is one, fittext<br> <ydaniv> lea: I know but would like to explore this<br> <ydaniv> astearns: tkent will prototype and we can see how people use it<br> <fantasai> +1 lea<br> <ydaniv> lea: still not optimal<br> <ydaniv> astearns: agree<br> <ydaniv> RESOLVED: use text-fit for now<br> <lea> s/lea: still not optimal/lea: if it's behind a flag authors don';t use it, then we ship it and we realize it doesn't serve use cases well/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12887#issuecomment-3524628665 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 November 2025 01:05:57 UTC