Re: [csswg-drafts] [css-fonts-5] Text Fitting: Scaling of things based on font-size (#12888)

The CSS Working Group just discussed `[css-fonts-5] Text Fitting: Scaling of things based on font-size`, and agreed to the following:

* `RESOLVED: start only with B, only text is scaled`

<details><summary>The full IRC log of that discussion</summary>
&lt;ydaniv> tkent: this issue is about  how other items align<br>
&lt;ydaniv> ... we had 3 options: A: all font-relative values are scaled based on font size<br>
&lt;kizu> q+<br>
&lt;astearns> q+<br>
&lt;ydaniv> ... b: nothing other than text should be scaled<br>
&lt;ydaniv> ... C: evenrhing should be scaled<br>
&lt;ydaniv> ... [shows example in slide]<br>
&lt;ydaniv> ... seems complexity is high when used with calc()<br>
&lt;ydaniv> ... (regarding to option A_<br>
&lt;TabAtkins> q+<br>
&lt;ydaniv> ... B is simple and we can extend later<br>
&lt;emilio> q+<br>
&lt;ydaniv> ... current impl. in Chrome is based on this<br>
&lt;kbabbitt> q+<br>
&lt;ydaniv> ... downside is non-text items can't be scaled<br>
&lt;ydaniv> ... [shows example in slides]<br>
&lt;ydaniv> q+<br>
&lt;ydaniv> ... in option A padding is re-evaluted<br>
&lt;florian> q+<br>
&lt;ydaniv> ... [missed]<br>
&lt;astearns> ack kizu<br>
&lt;ydaniv> kizu: I wanted to say there's discussion in the issue<br>
&lt;ydaniv> ... Chrome implemented B, works well, the main issue was that I wanted to have option A, don't think it's posisble but would like it<br>
&lt;ydaniv> ... don't think we should be limitting to one option<br>
&lt;ydaniv> ... also lea mentioned we may want other properties to fit/scale<br>
&lt;ydaniv> ... A and B could work in theory, we could implement A later<br>
&lt;ydaniv> ... if we would be able to do it later, we could fix later things that depend on font-size<br>
&lt;ydaniv> ... you could scale everything as much and later adjust other things accordingly<br>
&lt;ydaniv> ... you could mix and match all things<br>
&lt;ydaniv> ... think that combinations of other things should go to separate issue and we should consider them<br>
&lt;ydaniv> ... could be something like text-fit [missed]<br>
&lt;ydaniv> ... we don't yet what would be good by default<br>
&lt;ydaniv> ... we should start with option B and later continue on A<br>
&lt;ydaniv> astearns: on your last point, we don't have an explicit keyword for a default value<br>
&lt;ydaniv> ... I'd like to have an omittable dafault like auto<br>
&lt;ydaniv> ... in favor of doing B for now, even though A is cool<br>
&lt;ydaniv> ...  worried that the scaling factor is available to authors<br>
&lt;ydaniv> ... some non-text thing that could scale on the line, and have no way of finding out what that was<br>
&lt;astearns> ack astearns<br>
&lt;astearns> ack TabAtkins<br>
&lt;ydaniv> TabAtkins: similar to what astearns said, this has been done before, don't want to do A until we have some ways to solve it<br>
&lt;astearns> s/factor is available/factor is not available/<br>
&lt;ydaniv> ... I think there are good use-cases for B, like if your text has an inline image, it sould scale the same way<br>
&lt;astearns> ack emilio<br>
&lt;ydaniv> ... happy with starting with B as default, and have some keyword to allowing it, and later pusure A<br>
&lt;ydaniv> emilio: I guess sum() does something similar<br>
&lt;ydaniv> s/sum()/zoom/<br>
&lt;noamr> -q+<br>
&lt;astearns> s/we don't have an explicit/we don't have to have an explicit/<br>
&lt;ydaniv> ... is there a 4th option for doing a slightly better behavior?<br>
&lt;astearns> ack kbabbitt<br>
&lt;ydaniv> kbabbitt: I understand C is stay simple, B is just simple zoom of the text?<br>
&lt;noamr> q-<br>
&lt;ydaniv> iank_: it's not just zoom text, you're changing font-size , not just scale<br>
&lt;ydaniv> kbabbitt: so you're basically changing font-size<br>
&lt;ydaniv> iank_ :just for text<br>
&lt;ydaniv> kbabbitt: was wondering how would that work with text-decorations<br>
&lt;astearns> ack ydaniv<br>
&lt;TabAtkins> ydaniv: was wondering; I wasn't able to catch up with everything while scribing<br>
&lt;TabAtkins> ydaniv: does this work with SVG text?<br>
&lt;TabAtkins> ydaniv: that' snot just a text node<br>
&lt;TabAtkins> astearns: I think that should be a separate issue that we consider<br>
&lt;astearns> ack florian<br>
&lt;ydaniv> florian: I think we have to go with B<br>
&lt;ydaniv> ... taht said, there are non-simple things we want to do, but not necessarily bound to A<br>
&lt;ydaniv> ... proabbly should also work with units<br>
&lt;ydaniv> ... but maybe be able to opt-in to other systems, like to grow into something, like the box decorations<br>
&lt;astearns> treat-image-as-text generic feature?<br>
&lt;ydaniv> ... currently only B makes sense for now<br>
&lt;ydaniv> fantasai: strongly thins shouldn't go into style computation, like A describes<br>
&lt;ydaniv> ... the ablilty to scale and change font-size are both useful, but they are different<br>
&lt;ydaniv> ... want to remind that for other stuff like letter spacing, we have a sizing option that allows changing other stuff<br>
&lt;ydaniv> ... there are a number of places in text layout where we previously relied only on em's and they resolve later and we needed percentage to do that<br>
&lt;ydaniv> ... makes sense to me to use zoom<br>
&lt;ydaniv> astearns: just to clarify, you're saying let's not do A for em's, but we have to do A for %'s?<br>
&lt;ydaniv> fantasai: it could because it's based on a used-time operation<br>
&lt;ydaniv> TabAtkins: the way we do it now is do a one-shot guess, and later scale to fit<br>
&lt;ydaniv> ... in that case we would not have an accurate font-size necessarily<br>
&lt;ydaniv> fantasai: you could adjust decorations to that<br>
&lt;kizu> q+<br>
&lt;ydaniv> astearns: I think this would not be effective for authors who wouldn't know what that scale was<br>
&lt;astearns> ack fantasai<br>
&lt;ydaniv> fantasai: if you're zooming text and doubling the size of font, and don't scale the letter spacing with it, it would be very weird<br>
&lt;schenney> Also text-decoration-thickness: from-font;<br>
&lt;ydaniv> ... if it's set in %'s it supposed to match font-size<br>
&lt;ydaniv> kizu: doing with one-shot as now and later apply fitting and scaling, as browsers currently apply<br>
&lt;ydaniv> ... maybe we could later add a second shot<br>
&lt;ydaniv> ... maybe what fantasai said could also work<br>
&lt;ydaniv> astearns: one min before break<br>
&lt;iank_> for the 2-shot TBH i don't think its worth it, but it should be another issue.<br>
&lt;ydaniv> florian: maybe separate to 2 issues, we could do with B and check what it applies to<br>
&lt;ydaniv> ... maybe would be harder to guess what your sclae would be in a one-shot<br>
&lt;TabAtkins> +1 to florian<br>
&lt;ydaniv> ... the auto default should deal with text and we need to explore and it should include letter-spacing<br>
&lt;ydaniv> PROPOSED RESOLUTION: start only with B, only text is scaled<br>
&lt;ydaniv> astearns: any objections?<br>
&lt;ydaniv> RESOLVED: start only with B, only text is scaled<br>
&lt;fantasai> s/is scaled/is scaled, "what is text" TBD/<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12888#issuecomment-3524706648 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:33:19 UTC