- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Apr 2025 14:44:33 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-fonts-4] Feature for making text always fit the width of its parent`, and agreed to the following: * `RESOLVED: Start work on this in Fonts 5 and begin incubating.` * `RESOLVED: Roman as co-editor for Fonts 5` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> kizu: i have some slides<br> <TabAtkins> kizu: [presents slides]<br> <TabAtkins> kizu: this issue was opened back in 2018<br> <TabAtkins> kizu: therea re many libraries that try to do this effect<br> <TabAtkins> kizu: lots of typography examples in the real world, but it's not on the web<br> <TabAtkins> kizu: i wrote two articles about some pure-css techniques<br> <TabAtkins> kizu: these were my most popular articles, so clearly people want these features<br> <TabAtkins> kizu: here's an example of text sizing to fit its container<br> <TabAtkins> kizu: here's another example, obviously it's "fit to inline space", not necessarily width<br> <TabAtkins> kizu: fitting text is complicated, this is why we didn't ahve it for a long time<br> <TabAtkins> kizu: my workarounds are hacky, as usual<br> <TabAtkins> kizu: but it's possible.<br> <TabAtkins> kizu: there are no loops, it works<br> <TabAtkins> kizu: want to talk about some complexities<br> <TabAtkins> kizu: first issue is optical sizing<br> <TabAtkins> kizu: generally when we size text the size is proportional to its font-size, but opsz also lets the font respond to its size<br> <TabAtkins> kizu: see in this example, the change is non-linear. can even change the glyphs itself<br> <TabAtkins> kizu: another example, in cSS there can be fixed-size elements on the line, margins or letter-spacing, etc.<br> <TabAtkins> kizu: so just getting text width and calcualting a ratio doens't work<br> <TabAtkins> kizu: there are some cases you can't solve<br> <TabAtkins> kizu: but we don't necessarily need to solve these, okay for them to be broken. i have some ideas to minimize issues tho<br> <TabAtkins> kizu: one idea is when we first size the text, we freeze some values<br> <TabAtkins> kizu: this is the most complex part, but i don't think obscure cases should prevent us from solving common ones<br> <TabAtkins> kizu: common cases are straightforward, and fixed-size elements are solvable<br> <TabAtkins> kizu: i wont' go thru full details but here are a few<br> <TabAtkins> kizu: timing<br> <TabAtkins> kizu: i think it should happen when you first render text at normal font size, apply wrapping and balancing, then before justification alignment, we try to fit the text<br> <TabAtkins> kizu: this could be configurable<br> <TabAtkins> kizu: with freezing...<br> <TabAtkins> kizu: might need to render the text up to four times, but not more, to handle frozen sizes and optical sizing adjustments<br> <TabAtkins> kizu: in the first step we render as normal, then freeze the nonlinear dependencies. later renderings we use those frozen sizes<br> <TabAtkins> kizu: this allows us to know some variables in the algo, next time we can account for static space without freezing, then we can freeze them again in the final size. will make optical sizing approximately right, even if not exactly correct. looks good in my experiments<br> <TabAtkins> kizu: for the API, a few options<br> <TabAtkins> kizu: think we should start from font-size<br> <TabAtkins> kizu: font-size is our minimum size. this lets us do wrapping and balancing.<br> <TabAtkins> kizu: gives us better fallback too, if a browser doesn't support the resizing it'll be rendered as normal at the specified font size<br> <TabAtkins> kizu: and it's more accessible, font can't get too small to read<br> <TabAtkins> kizu: so no scaling down<br> <TabAtkins> kizu: a proposed proeprty is text-grow: <text-grow-type> || <max-font-size><br> <TabAtkins> kizu: <text-grow-type> = none | consistent | per-line<br> <TabAtkins> kizu: consistent is we consider all lines to have the same size. easier to implement, we just find the longest line box and then apply the font size to everything<br> <TabAtkins> kizu: per-line change each line independently, after wrapping<br> <astearns> q+ to ask about mixed font sizes<br> <TabAtkins> kizu: for <max-font-size>, i think we want it. if you don't have this the font can become too large. maybe a default of 100vb<br> <fantasai> I might suggest vmin<br> <TabAtkins> kizu: there's a codepen with a custom element that implements this algo<br> <florian> q+<br> <TabAtkins> kizu: all css, just some js to update a cq inside<br> <jensimmons> q+<br> <TabAtkins> kizu: all examples from this presentation are in the codepen<br> <TabAtkins> kizu: thanks to adam argyle for checking if this is viable in chrome, thanks to penelope who asked questions on bluesky, and thanks to roel nieskens<br> <TabAtkins> astearns: mixed font-sizes<br> <iank_> q+<br> <TabAtkins> astearns: similar to the case with non-text elements that are static<br> <TabAtkins> astearns: if the content itself has multiple font sizes on a line, how is that handled<br> <astearns> ack astearns<br> <Zakim> astearns, you wanted to ask about mixed font sizes<br> <TabAtkins> kizu: if font-size is in 'em' it works as expected<br> <TabAtkins> kizu: they'll scale with the rest of the text<br> <TabAtkins> kizu: there are some examples of that in my examples<br> <TabAtkins> astearns: i think for some, maybe most calculations that's the way to go<br> <TabAtkins> astearns: worried about specified font-size that has a calculation with min/max, want to make sure the result doesn't go over the specified max for the font-size calc *or* the resizing calc<br> <TabAtkins> kizu: there are some edge caess to consider. i think using the initial font-size for anything complex works for 99% of cases<br> <TabAtkins> kizu: if an author wants to do something complicated, i think they can work around it.<br> <astearns> ack florian<br> <astearns> q+<br> <TabAtkins> florian: i agree this is very desired<br> <TabAtkins> florian: and if we need to cut corners in some cases it'll be okay, people will work around<br> <kizu> Algorithm: https://www.tldraw.com/f/_sxU8eCZDcHbLvnDPMk4P<br> <kizu> CodePen: https://codepen.io/kizu/pen/QwWVXxQ<br> <kizu> My slides: https://drive.google.com/drive/folders/1og8QAU1m0QSaqxNGX6rSYUvQhfTy3PIq?usp=sharing (with videos, so not hosted on my site, will later make a pdf)<br> <TabAtkins> florian: one question, i think there are two cases (maybe more) where the avaialble inline-size for the line changes based on the height of the line<br> <TabAtkins> florian: floats and [another case]<br> <TabAtkins> florian: maybe it's in the algo, but not mentioned in the presentation. what happens if growing the height makes it narrower?<br> <TabAtkins> kizu: my example uses CQ so it requirest containment. could require that if we need to.<br> <TabAtkins> kizu: don't think we'd actually have a case where containment doesn't work but you want to fit a space<br> <kbabbitt> s/[another case]/fragmentation/<br> <TabAtkins> kizu: i think more complicated case is maybe initial-letter<br> <astearns> ack jensimmons<br> <TabAtkins> jensimmons: thanks for bringing this to the agenda, been talked about a long time<br> <TabAtkins> jensimmons: definitely something authors want, provides beautiful possibilities for headlines/etc<br> <bramus> +1<br> <TabAtkins> jensimmons: it seems like your whole thing assumes the way you want to grow is to increase font-size.<br> <TabAtkins> jensimmons: think that's common, but not necessarily only way<br> <astearns> q- (same point as jen)<br> <TabAtkins> jensimmons: maybe people want to keep the font-size but increase a font axis, like make it bolder<br> <astearns> q-<br> <TabAtkins> jensimmons: should maybe design it to do font-size scaling by default, but another control that lets you specify another control<br> <TabAtkins> jensimmons: probably just one, to keep it simple<br> <ChrisL> q+ to agree with jen<br> <TabAtkins> jensimmons: a lot of examples you showed are classic, but something in those examples is a lot of variation - one line super big, etc<br> <TabAtkins> jensimmons: interesting you broke it down between "consistent" and "per-line", but in your per-line it doesn't look like those posters<br> <noamr> q+<br> <TabAtkins> jensimmons: the amount of variation ends up pretty subtle, not as aesthetically pleasing<br> <TabAtkins> jensimmons: so something to think about<br> <TabAtkins> jensimmons: authors could force breaks, of course, making the worse rag ever before scaling<br> <astearns> +1 to having authored forced breaks for larger variation per line<br> <TabAtkins> jensimmons: authors would also possibly want to change the font per line<br> <TabAtkins> jensimmons: because we're thinking thru the order of operations, think there could be a spot, just before things are made bigger, you've got some pseudo-elements where you could set the font to something else<br> <TabAtkins> jensimmons: so then you'd linebreak, swap out fonts at the last minute, then scale to fit<br> <TabAtkins> jensimmons: i think if you want to emulate those classic layouts you have to think about this<br> <TabAtkins> kizu: for other axises - i was thinking about it, but couldn't come up with an algorithm that worked and was simple<br> <TabAtkins> kizu: increasing font-size is just increasing proportional to the available space, with some wrinkles<br> <TabAtkins> kizu: some fonts i saw coudl use optical sizing to achieve this effect.<br> <TabAtkins> kizu: but don't think we can generally substitute<br> <TabAtkins> kizu: other example, like increasing sapcing or using width axis, would be nice<br> <TabAtkins> kizu: i think we can start with width and then see if there's any other axises we can depend on<br> <TabAtkins> kizu: problem is axises aren't linear. not possible without looping<br> <TabAtkins> kizu: we can maybe start with just consistent version and then see if people need the per-line version<br> <TabAtkins> kizu: people can split the lines themselves for now, use a wrapper to apply different fonts<br> <TabAtkins> kizu: not sure what the blockers are for nth-line<br> <florian> q?<br> <TabAtkins> jensimmons: yeah, i get that what you've figured out so far doens't allow the other things to work, but we should think about it<br> <TabAtkins> jensimmons: stretch and weight are most important<br> <TabAtkins> jensimmons: optical sizing isnt' the way to pursue, i think. it's meant to be a tweak.<br> <TabAtkins> jensimmons: and should peg to font-size<br> <TabAtkins> jensimmons: but stretch and weight are two important options to make it bigger without changing font-size<br> <ChrisL> q?<br> <TabAtkins> kizu: yeah would be nice to have other controls, maybe possible to adjust the algorithm<br> <TabAtkins> kizu: but i think when you want to use other controls, having an ability to stretch just font-size would already be very helpful. eliminates one fo the things you need to tackle<br> <florian> q+<br> <TabAtkins> kizu: can just adjust your spacing initally, then have the browser auto-adjust the font-size to fit<br> <TabAtkins> jensimmons: right, just that variable fonts have already been invented, shoudl push ourselves to make sure it's possible to handle and we're not boxed out of handling that in the future<br> <TabAtkins> jensimmons: for second point, your reaction that it could be hard and we should maybe only do consistent, i think that's wrong. we should go for it.<br> <TabAtkins> jensimmons: this is something people have been thinking about since the days of cufon<br> <astearns> each line is the more important version, imo<br> <TabAtkins> jensimmons: we should be ambitious and figure it out<br> <TabAtkins> jensimmons: especially in the era of responsive design, using manual spans is a hack. letting wrapping happen then embiggening each line by itself is very attractive. just think we need to take it further<br> <astearns> ack iank_<br> <TabAtkins> iank_: one use-case we want to cover is shrinking, down to a minimum<br> <TabAtkins> iank_: say you're on a small-screen device, have a heading at a particular size, want to shrink down to a reasonable minimum size<br> <TabAtkins> iank_: think there's details to work out on how the actual scaling works<br> <TabAtkins> iank_: just optical sizing doesn't cover all the degenerate cases<br> <TabAtkins> iank_: one algo we might land on is effectively doing a transform, no additional glyph selection<br> <TabAtkins> iank_: don't want this to be restricted to varaible fonts that do support this feature<br> <TabAtkins> iank_: i just don't want us to get into a situation where we're bisecting the inline-size<br> <TabAtkins> iank_: i don't think we need to worry about containment here, like what florian brought up. floats are fine, we can just always move forward in the layout.<br> <TabAtkins> kizu: for transforms, was wondering if we wanted to do it this way<br> <florian> [walking forward seems reasonable]<br> <TabAtkins> kizu: but if there are non-text elements inside, like px margins, scaling might not look right<br> <TabAtkins> iank_: i mean could scale the individual text segments, not necessarily the atomic inlines<br> <TabAtkins> kizu: yeah could be good. would ahve to account for optical sizing<br> <RRSAgent> I have made the request to generate https://www.w3.org/2025/04/01-css-minutes.html fantasai<br> <TabAtkins> TabAtkins: Ian, I think you've been confused here - optical sizing isn't part of the proposal. it's just something that applies *when* you scale the size, if a font doesn't use it there's no issue<br> <TabAtkins> kizu: my proposal does a few passes, applies optical sizing at one point then freezes it.<br> <TabAtkins> kizu: currently four layouts, can skip them if there's no optical-sizing/etc<br> <iank_> teams just crashed for me - but i don't think that all the cases are covered by the number of passes.<br> <jensimmons> Yes, optical sizing just goes along for a ride when font sizing is made bigger or smaller. And it should do so here. Optical sizing is not designed to be _the mechanism_ for making a font bigger / smaller (in general, not just for this purpose).<br> <TabAtkins> ChrisL: agree with Jen, but i'd like to elaborate<br> <TabAtkins> ChrisL: given we already have variable fonts and they're becoming widespread, we shoudl design this primarily for variables<br> <TabAtkins> ChrisL: many things you can do with varaible that you can't do with, like, only 3 fonts<br> <TabAtkins> ChrisL: should just give reasonable results where you dont' have a variable font<br> <TabAtkins> ChrisL: agree that size is one thing authors want to change, but the width and weight are other things<br> <TabAtkins> ChrisL: not sure they'd want to just pick one<br> <TabAtkins> ChrisL: can imagine setting breakpoints<br> <alisonmaher> \me fantasai unfortunately the way that it was set up with the mics, it wasn't possible, but even so, the video camera in the room only shows people in the chairs closest to the front of the room<br> <jensimmons> q+<br> <astearns> ack ChrisL<br> <Zakim> ChrisL, you wanted to agree with jen<br> <TabAtkins> ChrisL: in terms of capabilities, people ahve wanted this for ages, convinced we should add but not sure exactly the details<br> <TabAtkins> ChrisL: this isn't bisection, just accounting for changes, optical-sizing when applied can adjust the size a little again<br> <TabAtkins> ChrisL: limited number of passes, not infinite looping<br> <jensimmons> Yeah, maybe we don't want to limit it to one variable axis. Perhaps we could add a mechanism for setting a ratio between them — 33% font-stretch + 66% font-weight<br> <jensimmons> or whatever the author wants, their ratio<br> <TabAtkins> kizu: might want to think further about variable axis, but maybe could be a seaprate feature<br> <ChrisL> qq+<br> <TabAtkins> kizu: could say in css "for this font, from Xpx to Ypx change this axis in this way". used similar to optical sizing<br> <TabAtkins> kizu: i think this might just be a separate feature then<br> <TabAtkins> astearns: time check, we're supposed to be on a break now. emptying queue<br> <astearns> ack ChrisL<br> <Zakim> ChrisL, you wanted to react to ChrisL<br> <TabAtkins> ChrisL: that feature does exist on opentype, a "composite" axis you declare in the font<br> <jensimmons> I disagree with what Roman just said, that everything should be tied to font size & we grow/shrink font-size in order to change the axis<br> <TabAtkins> ChrisL: %s of various other features<br> <TabAtkins> ChrisL: you can expose controls you want users to have, the width/etc are low-level.<br> <astearns> ack noamr<br> <TabAtkins> noamr: i wonder how much of this is seeking something more like svg scaling, just scaling the path as-is<br> <TabAtkins> noamr: svg text can fit to width, just icky right now<br> <TabAtkins> noamr: so i wonder if these are separate features so you don't need to deal with all the font complications<br> <astearns> ack florian<br> <TabAtkins> kizu: i'm not familiar with how it works in svg, can't answer<br> <TabAtkins> florian: folloiwng up, agree size isn't the only thing we want to vary<br> <TabAtkins> florian: okay with starting on size as long as th eproperty opts in<br> <TabAtkins> florian: in the example, max-font-size looks a bit special, we'll need other min/maxes<br> <TabAtkins> florian: so we should design the syntax so we can give constraints on everything we want to do<br> <TabAtkins> florian: but can start with the subset<br> <ChrisL> The SVG one is underspecified and is purely geometric scaling<br> <TabAtkins> florian: following up on Jen's line-by-line wanting extreme line differences, maybe when we turn this on we do different linebreaking<br> <noamr> Yes, I think in some cases what people seek is geometric scaling<br> <TabAtkins> florian: authors can also work around it, can use hidden <br> that are non-hidden by an @supports<br> <TabAtkins> florian: annoying, but when it's for a very specific heading or something, we have workarounds<br> <astearns> ack jensimmons<br> <TabAtkins> jensimmons: agreeing with Chris, taking back my smaller thinking, probably is good to have a mix of axises<br> <TabAtkins> jensimmons: probably should have a font model where we grow or shrink, but author can set up what that means. different %s of font-size/weight/stretch/etc<br> <TabAtkins> jensimmons: and if the author wants 100% font-size or whatever, they can get it<br> <TabAtkins> jensimmons: important to design so if you don't want font-size to change at all it doesn't change<br> <Kurt> Not quite the same behavior, but SVG also has textLength https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Attribute/textLength<br> <TabAtkins> astearns: since that could be quite complex, and we want to allow that sort of complexity, would it make sense to be able to express how you want things to resize in a @font-face rule?<br> <TabAtkins> astearns: that then applies in this property, go segment-by-segment to figure out what's allowed by the font being used<br> <TabAtkins> ChrisL: not sure that's the right palce for it, can see doing various controls depending on what space is available. @font-face makes it generic for all uses<br> <jensimmons> I also do not think the SVG thing is a solution. Font designers have carefully made text that looks fantastic at all sorts of sizes. Just growing text like it's an image ignores all of this work that's in the font.<br> <TabAtkins> florian: base don how you combine and limit the axises, need some room in the property to accommodate it. starting simple but going more complex.<br> <TabAtkins> astearns: so i'm hearing lots of feature requests, but no opposition to try and solve this.<br> <TabAtkins> astearns: should we have a resolution to start this in an ED?<br> <TabAtkins> TabAtkins: Fonts 5?<br> <TabAtkins> fantasai: not Inline. Maybe Text, but I think Fonts is best<br> <TabAtkins> ChrisL: Yes, Fonts<br> <TabAtkins> astearns: roman, are you volunteering or do you want someone else?<br> <TabAtkins> kizu: never written spec before, could collab<br> <TabAtkins> astearns: proposed resolution is to start working on this in Fonts 5, and we can open individual issues once there's some starting text<br> <TabAtkins> astearns: objections?<br> <bkardell> +1<br> <TabAtkins> RESOLVED: Start work on this in Fonts 5 and begin incubating.<br> <TabAtkins> astearns: appointing Romas as co-editor of Fonts 5<br> <TabAtkins> ChrisL: was going to entrap him but I'm okay with him going straight into it<br> <TabAtkins> RESOLVED: Roman as co-editor for Fonts 5<br> <noamr> jensimmons: it depends, sometimes authors want to animate the scaling in a way that fits in a particular box without changing anything but the geometry, using the text as something more decorative. I agree that it doesn't solve *everything* and that solving it on the font level is a lot more powerful<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2528#issuecomment-2769621512 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 April 2025 14:44:34 UTC