13:10:14 RRSAgent has joined #css 13:10:18 logging to https://www.w3.org/2025/04/01-css-irc 13:10:18 RRSAgent, make logs Public 13:10:19 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 13:11:00 present+ 13:11:15 ScribeNick: TabAtkins 13:11:16 present+ 13:11:39 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11824 13:11:40 Topic: [css-color-adjust-1] Forced Colors Mode Webdriver Emulation 13:11:40 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11824. 13:12:19 alisonmaher: this proposal is to add a new webdriver extension that keeps track of forced-color-mode emulation state, proposed light/dark 13:12:34 alisonmaher: it forces forced-color-mode if it's not none, and update the ysstem color mappings 13:12:41 alisonmaher: so it's a consistent experience across browsers 13:12:53 alisonmaher: put up a PR, using windows colors currently but we can do whatever 13:13:09 alisonmaher: so do we want to pursue? and not sure about process, if we need webdriver approval or just css 13:13:29 astearns: any webdriver already in? 13:13:42 alisonmaher: none in yet, but the multi-screen stuff has a proposal. i think this'll be the first. 13:13:56 astearns: anyone know how the webdriver folks like to have proposals put together? 13:14:08 alisonmaher: not sure. i looked at other webdriver specs, seemed better to put it in the sepc itself 13:14:12 alisonmaher: we can check 13:14:22 https://drafts.csswg.org/css-viewport/#automation is the webdriver part for viewports 13:14:30 TabAtkins: we took a resolution to put webdriver stuff in our specs a while back 13:14:37 ack fantasai 13:14:39 ...suggest we go with this for now and then check with webdriver folks 13:14:52 fantasai: tangential - how are we planning to test the final hookups to ensure it's working? 13:15:07 alisonmaher: when we test this we make the call to set one of the emulation states 13:15:22 alisonmaher: so the expectation would test the emulation's forced colors 13:15:51 alisonmaher: so we coudl use none to check it's not applied, then verify non-none works with different colors 13:16:17 fantasai: slightly different question acutally. we're gonna test this emulation, we can tell things are working as expected. 13:16:42 fantasai: but if you have a browser that supports teh webdriver emulation but doesn't acutally support asking the OS about the light/dark status, they should presumably fail *something* 13:16:48 lea has joined #css 13:16:55 alisonmaher: suppose could be thru the media query 13:17:04 fantasai: how do we test the MQ then? 13:17:21 q+ 13:17:39 astearns: your question is valid, but there's nothing in WPT that lets us close that final gap. it'll have to be something in the browser's own infrastructure that'll verify it work 13:17:52 fantasai: yeah my point is just that we should have some form of test that'll verify this 13:18:09 florian: as much as we like automated tests, i think there are some things that are impractical to test, and this might be one of them 13:18:13 ack emilio 13:18:35 emilio: similar. this feels like you'd need to tweak an OS setting, assume the browser wants to pay attention to that. 13:18:35 Even the browser's own testing infrastructure will be an emulation layer 13:18:44 present+ 13:18:48 emilio: like, firefox lets you force colors regardless of the OS, that's similar to what we're using in wpt 13:19:03 emilio: so wpt can test that there's a switch and that it works correctly, but it can't test when the browser decides to trigger that 13:19:16 fantasai: yeah, that just seems to be a hole in our testing plan 13:19:25 jensimmons has joined #css 13:19:25 alisonmaher: that seems to apply to testing system colors in general 13:19:33 alisonmaher: but this'll cover the rest of the space past that 13:19:41 fantasai: right, i think this is definitely an improvement. 13:19:44 present+ 13:19:52 fantasai: just be sure not to represent that this covers the whole space 13:19:59 astearns: so are we looking for a resolution to add this? 13:20:08 alisonmaher: yes, and i can do the extra work to double check with the webdriver folks 13:20:12 astearns: and would be easier with a spec in place 13:20:28 astearns: proposed resolution is to accept the PR, and go check with webdriver folks for approval 13:20:30 astearns: objections? 13:20:42 RESOLVED: Accept the PR, check with webdriver folks for approval 13:20:43 s/impractical to test, and this might be one of them/impractical to test automatically, and this might be one of them. We should still have shared tests but they'll have to involve manual steps 13:21:01 fantasai: process - forced colors is in CR, so we shoudl make edits in ED, ping webdriver, and then publish an updated CR 13:21:30 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11462 13:21:30 Topic: [css-align] `justify-items` and block splitting inline 13:21:30 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11462. 13:22:21 oriol: when justify-self:auto, spec says it should resolve to the value of justify-items of the parent box 13:22:33 oriol: there's one exception - when finding the position of an abspos item 13:22:42 oriol: this implies that "parent box" means containing block 13:22:56 oriol: with one exception - a block inside an inline. the inner block splits the inline 13:23:04 oriol: and the inline does not establisha containing block 13:23:12 oriol: so from which element should we take justify-items, if any? 13:23:22 oriol: taking it from parent inline seems weird to me 13:23:27 oriol: so not fond of the current spec text 13:23:34 oriol: another otpion is taking it from the CB 13:23:57 oriol: or Ian mentioned saying that, currently jsutify-items applies to all elements, we can say it doesn't apply to inline elements 13:24:12 oriol: so if the parent is inline, we'd treat justify-self:auto on the child as "normal" 13:24:20 oriol: no strong opintion, i think spec just didn't consider the case 13:24:23 ack fantasai 13:24:29 fantasai: you're right the spec didn't consider this case 13:24:36 fantasai: i think the intent of "look at the parent" was to do something simple 13:24:41 fantasai: which is why we didn't look at the CB 13:24:54 fantasai: two things that shoudl remain true are... 13:25:02 fantasai: i think we need to ignore anonymous boxes for this purpose 13:25:13 fantasai: for flex and grid they need to look at their parent, for abspos they dont' look at anything 13:25:22 fantasai: for here, probably shoudl do whatever is simplest 13:25:40 fantasai: whether it's look at parent element (doable during style resolution) or look at something else 13:25:42 flackr has joined #css 13:25:43 q+ 13:25:46 present+ 13:25:50 ack TabAtkins 13:25:54 TabAtkins: agree with fantasai , we should do the simple thing 13:25:59 TabAtkins: block-splitting-inlines are weird 13:26:09 TabAtkins: I would compute to normal, i.e. it doesn't take from it's parent if its parent is inline 13:26:19 TabAtkins: seems like easiest thing to do 13:26:25 q+ 13:26:39 ack florian 13:26:44 florian: in agreement, the msot intuitive thing is to walk up the tree until you find a block 13:26:55 florian: but this is a weird situation and doesn't really matter, so going to "normal" seems fine too 13:27:07 schenney has joined #css 13:27:16 i'd prefer "normal" 13:27:16 present+ 13:27:19 astearns: so proposed resolution from Tab is to have "auto" compute to "normal" if the parent is inline 13:27:43 oriol: i'm fine. not sure if it's actually simpler or not, in Servo we have the style fo the CB but not necessarily the parent. This sounds good to me tho 13:28:00 astearns: and interpreting Ian's comment as agreeing with TAb 13:28:02 astearns: objections? 13:28:28 florian: so this happens at style resolution time, right? so the fact that the inlne box isn't a parent of the block box at tree-building time doesn't matter, correct? 13:28:54 present+ 13:29:17 iank_: incorrect, i think we're the only one that *does* respect the parent/child relationship (we get filters correct, for example) 13:29:26 iank_: but i don't think it actually matters that much for this 13:30:10 astearns: so objections again? 13:30:26 RESOLVED: if parent is inline, then justify-self:auto computes to normal 13:30:42 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11460 13:30:42 Topic: [css-inline-3] Requiring authors to declare two values for `text-box-edge` is a mistake 13:30:42 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11460. 13:31:08 jensimmons: right now, t-b-e requires an author to specify both values 13:31:24 jensimmons: if they just say "cap" not "cap auto"/etc, then it's supposed to be invalid, but there's not interop 13:31:45 jensimmons: i think that's a mistake, i was writing an article in december and foudn it hard to teach because i had to teach the whol elinebox model 13:31:53 jensimmons: i think we should allow declaring just one and make some assumptions 13:32:05 https://github.com/w3c/csswg-drafts/issues/11460#issuecomment-2769319469 13:32:05 jensimmons: if they declare cap/edge/alphabetic, we assume the other is auto 13:32:44 The whole model is indeed complex to understand. I support making easy things easy, and letting authors get what they want without needing to understand the whole thing if we can. 13:32:49 jensimmons: there's a question about.... shouldn't we try to do something more magic for authors? like if you are trimming the cap edge you probably want to also trim the alphabetic edge. this started from an author request to trim both with just one value 13:33:26 jensimmons: but when i was makign demos, i foudn there are plenty of times you do want to trim to both cap and alphabetic, but there are plenty of times you want to do something different too. so i think we should just default "auto" for the missing one 13:33:36 +1 to this proposal from me, I think it makes sense to default to auto 13:33:45 s/default/default omitted values/ 13:33:52 s/what they want without/what they probably want without 13:33:59 astearns: any concern that each individual value expands to the correct two values differently? 13:34:16 astearns: is that hard to teach, or is it more like any partiuclar author is only using a few of these, and our default expansion for that value is probably what they want 13:34:38 jensimmons: i think for "text" becoming "text text"/etc I think it's pretty obvious, tho I'd be interested in hearing if someone thinks differently 13:34:59 jensimmons: you don't in one rule that "ideographic" and "cap". you might mix them on one page, but they'll be on different elements 13:35:13 ack fantasai 13:35:31 fantasai: we have a bunch of places where if you *can* duplicate the value, we do, and we do something else if we can't 13:35:37 dholbert has joined #css 13:35:46 present+ 13:35:52 astearns: yeah, this is just a little more complex, since you have "auto" sometimes in first, sometimes in second 13:36:17 fantasai: you're basically default the "other" value. it's like background-position, if you say "left" you get "center left", if you say "top" you get "top center" 13:36:29 q+ 13:36:35 jensimmons: question is just if someone is doing ideographic a lot, is "ideographic" alone implying doubled? 13:36:49 florian: doing it both ways makes the most sense by defualt. i agree with the proposal 13:37:04 florian: just give people what they likely want by default without having to udnerstand the whole model 13:37:14 ack kizu 13:37:23 jensimmons: yeah, just should have a default rather than the current bheavior which is invalid, which doesn't do anything 13:37:34 s/doing it both ways/doing ideographic both ways 13:37:59 kizu: as an author, if we could have alphabetic/ideographic as shorter keywords, a bit long to write when we have other shorthands like "cap" 13:38:13 kizu: like "cap a" instead of "cap alphabetic" 13:38:23 astearns: probably fair, but a separate issue 13:38:38 +1 to the proposal 13:38:49 astearns: comments? objections? 13:39:14 RESOLVED: Allow text-box-edge to take a single keyword, expanding as specified in Jen's final comment 13:39:28 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11472 13:39:28 Topic: [css-inline-3] text-box accumulation unexpected behavior 13:39:28 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11472. 13:39:44 fantasai: probably helpful to look at the issue examples 13:39:57 fantasai: an author was playing with text-box-trim and was surprised when it cut into a button he'd styled 13:40:32 fantasai: reason is because, normally if you have padding/etc we dont' trim thru the padding/border. but the button was an inline block, so it sits on a line, and we ignore the contents of lineboxes when trimming. we just trim to the root inline box no matter what's on the line. 13:40:53 fantasai: it seems like this is something that people will trip over as well. there are workarounds, but there are reasons the author might have wanted to use inline-block specifically 13:41:03 fantasai: so options are we could make authors work around this 13:41:28 fantasai: or we could make a rule that says if you have an inline-block on a line, that pushes out the text edge to the margin edge of that block. (rather, any atomic inline, not just inline-blocks) 13:41:50 fantasai: so the rule for text trim would introspect into the linebox content, and if it finds an atomic inline it would push the edge out 13:41:56 fantasai: so wanted to check the wg's opinion 13:42:04 jensimmons: if we made the second change... 13:42:24 jensimmons: i could also see this author applying text-box-trim to the button itself to get the text vertically centered 13:42:28 jensimmons: will that get screwy? 13:42:43 fantasai: no, because it'll push to the amrgin edge fo the box *after* the box's position ahs been computed 13:43:05 q+ 13:43:10 fantasai: if they were using text-box-trim on the button itself that'll change the button's sizing. then if it's on the paragraph too, we don't care about *how* the atomic inline figured out its margin box, we'll just use that 13:43:14 ack dbaron 13:43:24 are you sure you want margin-box and not border-box? e.g. margins on inline-blocks are typically used to pad the line-box. 13:43:34 dbaron: i think from a high level persepctive the result you want makes sense. 13:43:38 iank_, yes I'm sure 13:43:49 dbaron: tryign to remember how text-box-edge works, waiting for the spec to load 13:44:05 iank_, I think if the author asked for that extra space, we should give it to them 13:44:12 ack florian 13:44:15 florian: maybe a silly question 13:44:29 florian: would it be an option to go with border edge rather than margin edge? or am i missing something? 13:44:31 iank_, ... although I suppose maybe it's similar to margin collapsing 13:44:37 iank_, hmmm 13:44:42 q+ 13:44:49 dbaron: i think we're reasonably consistent that waht matters for atomic inlines is their margin edge 13:45:16 iank_: i ahd the same question. margins are typically used to simulate the same metrics as the text around it. so if margins are used that way it makes sense to trim to the border box, i think 13:45:32 iank_: becuase if they're being used to simulate a descent, and you're trying to trim the descent 13:45:33 ack kizu 13:45:59 kizu: if we want this behavior, we need a way for an element to opt out, if it *wants* to hang from the line you're trimming to 13:46:23 kizu: if we use margin box you could use negative margin to bring it back down (unless we do something magic there to not consider negative margin for text-trim) 13:46:47 astearns: similar question. first option was make the author fix it. if we change the default behavior, can they fix our choice? 13:47:09 fantasai: i think roman's point is correct. if we use the margin edge, author can use negative margin to shift that edge inward 13:47:16 fantasai: but if we use the border edge, author has no control 13:47:52 fantasai: so proposed reoslution is text-box-trim does not trim further into the linebox than the outermost margin edge of any atomic inlines in the linebox 13:48:03 astearns: and that's sufficient to solve this author's issue? 13:48:06 fantasai: i believe so 13:48:12 astearns: objections? 13:48:26 RESOLVED: text-box-trim does not trim further into the linebox than the outermost margin edge of any atomic inlines in the linebox 13:48:40 (I presume this affects how text-box-trim affects block containers.) 13:48:43 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11365 13:48:43 Topic: [css-inline-3] -top/-bottom vs -over/-under 13:48:43 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11365. 13:49:05 fantasai: in 10713 we resolved to add reorderable kewyrods to text-box-edge 13:49:12 fantasai: i didn't edit that into the spec yet because i ran into this issue 13:49:16 fantasai: what keywords do we actually want 13:49:30 fantasai: in horizontal text top/bottom are pretty obvious. we ahve text-top/text-bottom etc 13:49:35 fantasai: when you have vertical it's more interesting 13:49:43 s/kewyrods/keywords 13:49:56 fantasai: in our specs, and in things like ruby-position, we use the terms over/under to refer to "above the baseline" and "below the baseline" 13:50:19 fantasai: so what keywords do we want to use for text-edge? top/bottom, or over/under, or a mix? text-top and ideographic-over? 13:50:35 fantasai: murakami-san proposed we be consistent with top/bottom keywords we have already. 13:50:45 fantasai: i don't have a strong opinion, we just need to resolve on that 13:51:53 florian: so that would be consistent with the opentype naming? 13:52:06 fantasai: so over is sometimes top, sometimes left, sometime sright, depending on WM 13:52:14 fantasai: top in CSS, aside from vertical-align, is always page top 13:52:22 fantasai: but in vertical-align it's the over/udner side 13:52:30 fantasai: which can be left/right 13:53:08 TabAtkins: i was just confused, i thought florian was saying the opentype "top" wasn't always the css "over" 13:53:12 fantasai: no, it's always the same 13:53:24 jensimmons: so everyone's consistent that "top" isn't always top 13:54:08 astearns: and we can always go with top/bottom for now and always add over/under in the future as aliases if we need to 13:54:10 fantasai: yeah we could 13:54:15 florian: don't expect we'll need to tho 13:54:26 astearns: so proposed resolution is we stay with text-top/text-bottom? 13:54:36 fantasai: -top and -bottom for all keywords in this property 13:54:39 astearns: objection? 13:55:04 RESOLVED: use -top and -bottom as the direction suffix for all keywords in this property (referring to over/under) 13:55:25 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10713 13:55:25 Topic: [css-inline-3] Allow re-ordering of keywords 13:55:25 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10713. 13:55:43 fantasai: I think the last issue is what was blocking this issue, so assuming we're still fine with the reordering I'll make these edits 13:55:55 fantasai: #11365 13:56:34 github-bot, take up https://github.com/w3c/csswg-drafts/issues/2528 13:56:34 Topic: [css-fonts-4] Feature for making text always fit the width of its parent 13:56:34 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/2528. 13:56:40 kizu: i have some slides 13:57:27 kizu: [presents slides] 13:57:40 kizu: this issue was opened back in 2018 13:57:59 kizu: therea re many libraries that try to do this effect 13:58:09 kizu: lots of typography examples in the real world, but it's not on the web 13:58:27 kizu: i wrote two articles about some pure-css techniques 13:58:42 kizu: these were my most popular articles, so clearly people want these features 13:59:00 kizu: here's an example of text sizing to fit its container 13:59:21 kizu: here's another example, obviously it's "fit to inline space", not necessarily width 13:59:43 kizu: fitting text is complicated, this is why we didn't ahve it for a long time 13:59:50 kizu: my workarounds are hacky, as usual 13:59:57 kizu: but it's possible. 14:00:02 kizu: there are no loops, it works 14:00:11 kizu: want to talk about some complexities 14:00:19 kizu: first issue is optical sizing 14:00:43 kizu: generally when we size text the size is proportional to its font-size, but opsz also lets the font respond to its size 14:01:04 kizu: see in this example, the change is non-linear. can even change the glyphs itself 14:01:15 nigel has joined #css 14:01:35 kizu: another example, in cSS there can be fixed-size elements on the line, margins or letter-spacing, etc. 14:01:44 kizu: so just getting text width and calcualting a ratio doens't work 14:01:58 kizu: there are some cases you can't solve 14:02:22 kizu: but we don't necessarily need to solve these, okay for them to be broken. i have some ideas to minimize issues tho 14:02:39 kizu: one idea is when we first size the text, we freeze some values 14:02:54 kizu: this is the most complex part, but i don't think obscure cases should prevent us from solving common ones 14:03:05 kizu: common cases are straightforward, and fixed-size elements are solvable 14:03:14 kizu: i wont' go thru full details but here are a few 14:03:16 kizu: timing 14:03:43 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 14:03:47 kizu: this could be configurable 14:04:08 kizu: with freezing... 14:04:18 kizu: might need to render the text up to four times, but not more, to handle frozen sizes and optical sizing adjustments 14:04:48 kizu: in the first step we render as normal, then freeze the nonlinear dependencies. later renderings we use those frozen sizes 14:05:33 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 14:05:40 kizu: for the API, a few options 14:05:48 kizu: think we should start from font-size 14:06:03 kizu: font-size is our minimum size. this lets us do wrapping and balancing. 14:06:40 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 14:06:53 kizu: and it's more accessible, font can't get too small to read 14:07:04 kizu: so no scaling down 14:07:22 kizu: a proposed proeprty is text-grow: || 14:07:33 kizu: = none | consistent | per-line 14:08:02 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 14:08:11 kizu: per-line change each line independently, after wrapping 14:08:14 q+ to ask about mixed font sizes 14:09:01 kizu: for , i think we want it. if you don't have this the font can become too large. maybe a default of 100vb 14:09:12 I might suggest vmin 14:09:34 kizu: there's a codepen with a custom element that implements this algo 14:09:43 q+ 14:09:45 kizu: all css, just some js to update a cq inside 14:09:53 q+ 14:09:55 kizu: all examples from this presentation are in the codepen 14:10:24 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 14:10:37 astearns: mixed font-sizes 14:10:41 q+ 14:10:48 astearns: similar to the case with non-text elements that are static 14:10:56 astearns: if the content itself has multiple font sizes on a line, how is that handled 14:10:58 ack astearns 14:10:58 astearns, you wanted to ask about mixed font sizes 14:11:07 kizu: if font-size is in 'em' it works as expected 14:11:24 kizu: they'll scale with the rest of the text 14:11:42 kizu: there are some examples of that in my examples 14:12:10 astearns: i think for some, maybe most calculations that's the way to go 14:12:36 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 14:13:00 kizu: there are some edge caess to consider. i think using the initial font-size for anything complex works for 99% of cases 14:13:19 kizu: if an author wants to do something complicated, i think they can work around it. 14:13:20 ack florian 14:13:27 q+ 14:13:28 florian: i agree this is very desired 14:13:37 florian: and if we need to cut corners in some cases it'll be okay, people will work around 14:13:44 Algorithm: https://www.tldraw.com/f/_sxU8eCZDcHbLvnDPMk4P 14:13:44 CodePen: https://codepen.io/kizu/pen/QwWVXxQ 14:13:44 My slides: https://drive.google.com/drive/folders/1og8QAU1m0QSaqxNGX6rSYUvQhfTy3PIq?usp=sharing (with videos, so not hosted on my site, will later make a pdf) 14:13:47 ntim has joined #css 14:13:58 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 14:14:03 florian: floats and [another case] 14:14:04 present+ 14:14:17 florian: maybe it's in the algo, but not mentioned in the presentation. what happens if growing the height makes it narrower? 14:14:34 kizu: my example uses CQ so it requirest containment. could require that if we need to. 14:14:48 kizu: don't think we'd actually have a case where containment doesn't work but you want to fit a space 14:14:49 s/[another case]/fragmentation/ 14:14:59 kizu: i think more complicated case is maybe initial-letter 14:15:03 ack jensimmons 14:15:17 jensimmons: thanks for bringing this to the agenda, been talked about a long time 14:15:29 jensimmons: definitely something authors want, provides beautiful possibilities for headlines/etc 14:15:31 +1 14:15:46 jensimmons: it seems like your whole thing assumes the way you want to grow is to increase font-size. 14:15:53 jensimmons: think that's common, but not necessarily only way 14:16:07 q- (same point as jen) 14:16:08 jensimmons: maybe people want to keep the font-size but increase a font axis, like make it bolder 14:16:10 q- 14:16:28 jensimmons: should maybe design it to do font-size scaling by default, but another control that lets you specify another control 14:16:32 jensimmons: probably just one, to keep it simple 14:16:37 q+ to agree with jen 14:17:05 jensimmons: a lot of examples you showed are classic, but something in those examples is a lot of variation - one line super big, etc 14:17:28 jensimmons: interesting you broke it down between "consistent" and "per-line", but in your per-line it doesn't look like those posters 14:17:48 q+ 14:17:50 jensimmons: the amount of variation ends up pretty subtle, not as aesthetically pleasing 14:17:54 jensimmons: so something to think about 14:18:11 jensimmons: authors could force breaks, of course, making the worse rag ever before scaling 14:18:19 +1 to having authored forced breaks for larger variation per line 14:18:21 jensimmons: authors would also possibly want to change the font per line 14:18:54 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 14:19:13 jensimmons: so then you'd linebreak, swap out fonts at the last minute, then scale to fit 14:19:33 jensimmons: i think if you want to emulate those classic layouts you have to think about this 14:20:04 kizu: for other axises - i was thinking about it, but couldn't come up with an algorithm that worked and was simple 14:20:15 kizu: increasing font-size is just increasing proportional to the available space, with some wrinkles 14:20:27 kizu: some fonts i saw coudl use optical sizing to achieve this effect. 14:20:35 kizu: but don't think we can generally substitute 14:20:47 kizu: other example, like increasing sapcing or using width axis, would be nice 14:20:58 kizu: i think we can start with width and then see if there's any other axises we can depend on 14:21:15 kizu: problem is axises aren't linear. not possible without looping 14:21:38 kizu: we can maybe start with just consistent version and then see if people need the per-line version 14:21:53 kizu: people can split the lines themselves for now, use a wrapper to apply different fonts 14:21:58 kizu: not sure what the blockers are for nth-line 14:22:17 q? 14:22:20 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 14:22:27 jensimmons: stretch and weight are most important 14:22:38 jensimmons: optical sizing isnt' the way to pursue, i think. it's meant to be a tweak. 14:22:42 jensimmons: and should peg to font-size 14:22:58 jensimmons: but stretch and weight are two important options to make it bigger without changing font-size 14:23:04 q? 14:23:31 kizu: yeah would be nice to have other controls, maybe possible to adjust the algorithm 14:23:54 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 14:24:06 q+ 14:24:09 kizu: can just adjust your spacing initally, then have the browser auto-adjust the font-size to fit 14:24:34 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 14:24:56 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. 14:25:05 jensimmons: this is something people have been thinking about since the days of cufon 14:25:06 each line is the more important version, imo 14:25:16 jensimmons: we should be ambitious and figure it out 14:25:53 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 14:26:15 ack iank_ 14:26:33 iank_: one use-case we want to cover is shrinking, down to a minimum 14:26:56 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 14:27:06 iank_: think there's details to work out on how the actual scaling works 14:27:15 iank_: just optical sizing doesn't cover all the degenerate cases 14:27:29 iank_: one algo we might land on is effectively doing a transform, no additional glyph selection 14:27:43 iank_: don't want this to be restricted to varaible fonts that do support this feature 14:28:05 iank_: i just don't want us to get into a situation where we're bisecting the inline-size 14:28:34 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. 14:28:45 kizu: for transforms, was wondering if we wanted to do it this way 14:28:49 [walking forward seems reasonable] 14:28:59 kizu: but if there are non-text elements inside, like px margins, scaling might not look right 14:29:17 iank_: i mean could scale the individual text segments, not necessarily the atomic inlines 14:29:31 kizu: yeah could be good. would ahve to account for optical sizing 14:30:27 I have made the request to generate https://www.w3.org/2025/04/01-css-minutes.html fantasai 14:30:35 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 14:30:50 kizu: my proposal does a few passes, applies optical sizing at one point then freezes it. 14:31:03 kizu: currently four layouts, can skip them if there's no optical-sizing/etc 14:31:03 teams just crashed for me - but i don't think that all the cases are covered by the number of passes. 14:31:16 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). 14:31:43 ChrisL: agree with Jen, but i'd like to elaborate 14:31:55 ChrisL: given we already have variable fonts and they're becoming widespread, we shoudl design this primarily for variables 14:32:06 ChrisL: many things you can do with varaible that you can't do with, like, only 3 fonts 14:32:18 ChrisL: should just give reasonable results where you dont' have a variable font 14:32:30 ChrisL: agree that size is one thing authors want to change, but the width and weight are other things 14:32:36 ChrisL: not sure they'd want to just pick one 14:32:41 ChrisL: can imagine setting breakpoints 14:32:55 \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 14:33:01 q+ 14:33:03 ack ChrisL 14:33:03 ChrisL, you wanted to agree with jen 14:33:03 ChrisL: in terms of capabilities, people ahve wanted this for ages, convinced we should add but not sure exactly the details 14:33:18 ChrisL: this isn't bisection, just accounting for changes, optical-sizing when applied can adjust the size a little again 14:33:29 ChrisL: limited number of passes, not infinite looping 14:33:29 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 14:33:43 or whatever the author wants, their ratio 14:33:44 kizu: might want to think further about variable axis, but maybe could be a seaprate feature 14:33:58 qq+ 14:34:08 kizu: could say in css "for this font, from Xpx to Ypx change this axis in this way". used similar to optical sizing 14:34:22