00:28:44 emeyer has left #css 02:08:21 jensimmons has joined #css 02:59:35 Zakim has left #css 03:06:28 dbaron: yes, the former is a direct link to the file, which manually redirects via JS to the drafts.csswg.org url (see line 783 of that spec). drafts.csswg.org then hits plinss's server, which reverse proxies back to the github.io file 03:06:54 probably i should change that script to just do a history replace instead of a redirect, lol 03:25:18 dholbert has joined #css 12:57:02 RRSAgent has joined #css 12:57:02 logging to https://www.w3.org/2025/04/02-css-irc 12:57:04 RRSAgent, make logs Public 12:57:05 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 12:59:31 kizu has joined #css 12:59:35 present+ 12:59:54 emeyer has joined #css 12:59:58 present+ 13:00:09 present+ 13:01:36 present+ 13:02:52 present+ 13:02:58 present+ 13:02:59 jfkthame has joined #css 13:03:19 ScribeNick: TabAtkins 13:03:40 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10827 13:03:40 Topic: [css-overflow] `text-wrap-style` interaction with height-based `line-clamp` 13:03:40 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10827. 13:03:41 present+ 13:04:40 your audio isn't working in the room 13:05:35 remote people can hear everything (including room) 13:05:38 🎶 13:06:09 present+ 13:06:59 present+ 13:08:27 Present+ 13:08:40 present+ 13:09:17 andreubotella: we'd previously resolved that when you have text-wrap:balance in a paragraph that's in a line-clamp container 13:09:35 andreubotella: line-clamp first clamps, then text-wrap balances 13:10:04 andreubotella: now the q is what happens when you have line-clamp:auto and a height, which determines the clamp 13:10:16 andreubotella: florian said earlier that you'd first do layout with tet-wrap:balance then clamp based on that 13:10:36 andreubotella: i think that's accurate. but i'm not sure that will work, adn seems to go agaisnt what we previously resolved 13:11:03 https://codepen.io/andreubotella/pen/ByaOBMz 13:11:21 andreubotella: so here if we have line-clamp:2 and balance 13:12:00 andreubotella: so in the first, you wrap four items per line and clamp after the second. 13:12:05 ydaniv has joined #css 13:12:12 q+ 13:12:19 andreubotella: but in the second you have only balance, and you get three itmes per line. if you clamped at the second line you'd only see 6 items 13:13:12 andreubotella: there's still a requirement that you don't grow 13:13:38 andreubotella: [shows example where items that balance to the third row have a higher line-height, so if you didn't balance and they went to thes econd line, they'd grow the box] 13:14:05 andreubotella: chrome's impl of text-wrap:pretty also only works on the lines before the clamp 13:14:09 andreubotella: so it has the same limitations 13:14:18 ack florian 13:14:21 q+ 13:14:24 florian: i think we have three things we're trying to take into account 13:14:30 florian: first, what does it look like when it's clamped 13:14:44 florian: second, the clamping might be dynamic with the user hiding/revealing, so does it look reasonable when you hdie and show 13:14:50 florian: third, try to keep the algo sensible 13:15:08 florian: i think we ahd a discussion at tpac. what i wrote at the issue wasn't just my idea iirc, was partially consesnus 13:15:31 florian: idea is you first do a regular layout (balance, pretty, etc), then you find the clamp point, discard remaining content, insert ellipsis on last line, then rebalance only the visible part 13:15:47 florian: that last step was important, ian mentioned if you insert the ellipsis and dont' rebalance people can be upset 13:15:56 florian: the ellipsis can unbalance that last line, especially if it's not just ... 13:16:03 florian: so i think that was roughly the idea we were going for 13:16:27 florian: if you do what's in Andreu's left example, when you unclamp it'll either dramatically rebalance, or not balance at all 13:16:38 andreubotella: yeah, [shows off turning off clamp, it rebalances]s 13:17:01 andreubotella: so this is what browsers do right now. tension between not reflowing when you hide/show, and the handling of stuff before the clamp 13:17:21 andreubotella: in this case if you balance before clamp, then insert ellipsis, this does not look *un*balanced, but it look like there's more room for content 13:17:27 ack iank_ 13:17:44 iank_: the reason balancing is important after clamping is you can end up with very unbalanced lines, ignoring the ellipsis issue 13:17:52 iank_: this was the first piece of feedback we got from people using the feature 13:17:52 q+ 13:18:02 iank_: we first balanced then clamped, and immediatley several users complained 13:18:19 iank_: my pref here is just to layout initially without balance or pretty, then clamp, then apply balancing 13:18:27 iank_: this also seems like something we can potentially change later 13:18:39 iank_: all browsers have that behavior today and we haven't gotten negative feedback 13:18:57 iank_: so my bias is to do nothing, keep the existing before (clamp before balancing), and if we get negative feedback we can chagne it 13:19:06 astearns: when you say do initial layout, then clamp, then apply balancing 13:19:18 astearns: you're balancing only the content that's been clamped? 13:19:39 [yes, you balance the content that is visible after clamping] 13:19:56 astearns: second question, for people who didn't like the lack of balancing, assuming they're okay with the reflow when you reveal what's after the clamp? 13:20:37 iank_: yeah, we got feedback from pretty alrge sites, they do reveal, and didn't ahve negative feedback about that. maybe they haven't thought about it much, but they seem to hate the early balancing more 13:20:46 q+ 13:20:52 ack astearns 13:20:56 iank_: other things that change height can change the layout, and that's ok, we are changing the height. all the elements areound it are growing and shrinking 13:21:04 q+ 13:21:08 ack fantasai 13:21:12 fantasai: i think that makes sense, when you reveal you don't want to rebalance everything 13:21:31 q+ 13:21:36 fantasai: for pretty, in an impl where it affects all the lines having a reveal effect reflow the whole first half of the paragraph might be uncomfortable 13:21:52 s/you don't/you do/ 13:22:19 fantasai: not sure the best answer, just noting the layout might have some hysteresis effect 13:22:32 astearns: i think i disagree, the same reflow concerns apply to both balance and pretty 13:22:42 astearns: the reflow might be an issue, but if it is, it's an issue for both 13:22:58 fantasai: i think in the balance case the user will expect the reflowing, they expect it to be balanced in both cases, and that requires a reflow 13:23:08 fantasai: but for pretty the effects are more subtle, and the user might not expect a reflow to cross that line 13:23:10 ack florian 13:23:36 florian: adding to this, i have different levels of discomfort when you ahve a toggle - when you're doing it progressively like a height-based clamp 13:23:50 q- 13:23:59 florian: if you drag progressively and reveal lines, the whole thing rejiggles and rebalances every time, that feels uncomfortable. some stability woudl be nice 13:24:28 florian: i wonder if the gain from a progressive reveal might be worth it. but this isn't a hell i'm interested in staying in forver. 13:24:50 florian: i'm just concerned by the progressive reveal case 13:24:53 iank_: two things there 13:25:05 iank_: depending on limits, we stop balancing after a certain number of lines anyway, so it'll become stable 13:25:18 present+ 13:25:24 iank_: if you're dragging something, typically other things are reflowing on the page too, so keeping this one thing stable isn't as important i think 13:25:35 iank_: but again, if we do get strong feedback in the opposite direction, this is potentially changeable 13:25:37 ack andreubotella 13:25:51 Yeah agreed this seems not very risky to change either way 13:26:25 andreubotella: one thing i think we need to make sure we consdier is, if we have a first layout without balance, then use that for clamp, that shoudl not affect balanced paragraphs before that point. so if the clamp happens in the *second* paragraph it only affects that paragraph 13:26:51 andreubotella: we don't want to disable text-wrap:balance in the first layout pass for everything, we just want to know the lines of the current paragraph without balancing 13:27:04 alisonmaher has joined #css 13:27:05 andreubotella: don't know if what i said affects different impls, but i think it's something we should decide on 13:27:07 q+ 13:27:07 +1 emilio 13:27:08 ack fantasai 13:27:33 fantasai: on the progressive reveal case, i think the user *would* expect rebalancing on each line, but for pretty they *woudln't* expect it 13:27:48 fantasai: for ian's point about we only balance a few lines anyway, webkit balances unlimited lines, so that's not true across impls 13:28:09 fantasai: re: tweaking later, i agree, and emilio does too. so we can pick what's best for now and adjust for user feedback, don't think it'll make a compat problem 13:28:19 fantasai: but we should try to do the right thing from the beginning 13:28:40 fantasai: so yeah for text-wrap:balance i do think we want it balanced at each point, and for pretty we want to allow the UA to maintain stability if they want to 13:28:45 astearns: i do think we should be consistent 13:28:58 astearns: we ahve the stable versions of text-wrap that are perfect for that gradual reveal without line jiggling 13:29:10 florian: i agree with elika on this point, stable is about introducing text 13:29:14 ack florian 13:29:16 astearns: i just mean "not balanced", auto included 13:29:22 s/introducing/inserting/ 13:29:36 florian: okay. but it's about "does it look nice", and if you do balance, it's easy to look bad if you don't do what Ian is saying 13:29:46 florian: but for pretty it probably doesn't look that bad. 13:29:56 florian: it's not two-line headers, that's not what you apply pretty to 13:30:01 florian: it's the beginning of an article 13:30:06 astearns: i understand the article, but i disagree 13:30:18 I think we can just let pretty up to UAs for the moment 13:30:25 astearns: i think people are using pretty to avoid orphans, and if we're not relaying out as pretty each time, you can end up with orphans on the clamped line 13:30:34 astearns: so people will wonder why something isn't pretty 13:30:40 florian: pretty isn't "avoid orphans" 13:30:45 astearns: i know, but it's what people use it for now 13:31:01 TabAtkins: [repeats Ian's line from IRC] 13:31:14 fantasai: so it sounds like we want to specify that balancing is applied after clamping, not before 13:31:33 andreubotella: and the interaction with clamping based on height 13:31:42 andreubotella: so to what extent would it be okay to leave that impl-defined 13:32:00 florian: i think we can say that *when* you do rebalancing after clamping, you don't re-check if your clamp point is fine after jiggling 13:32:09 florian: you just keep using the initial clamp point 13:32:15 s/understand the article/understand the argument/ 13:32:24 florian: might need some bounds on your balancing argument, because a rejiggling might move tall items around to change the height 13:32:38 florian: i think that's currently implied by the spec's note, but maybe not clear 13:32:46 dholbert has joined #css 13:32:50 present+ 13:33:05 i think for `height:auto` you can progressively step back the line-clamp line to get the correct behaviour 13:33:17 florian: so a few resolutions. for balance, first clamp then balance. for pretty, up to the UA. in either case, the rearranging of lines that happen after clamping doesn't re-trigger clamping 13:33:38 florian: if you calmp at 200px the rebalancing shoudln't give you 250px 13:33:43 florian: so this needs to be taken into account 13:34:13 TabAtkins: [describe's Ian's comment] 13:34:20 fantasai: I think that's probably the right result for height-based clampding 13:34:36 florian: I think we had earlier versions of balance/pretty that said it *couldn't* grow you rcontent 13:34:49 florian: maybe we go back to that version when doing height clamping 13:35:17 fantasai: i'm a little confused. if rebalancing grows your height, i think stepping back a line is what the author woudl expect 13:35:26 fantasai: i think we could require that you're only required to do this step-back once 13:35:54 andreubotella: one thing that could happen is that rebalancing could *shrink* your content and give space enough for another line, i think we don't want to add another line 13:35:57 fantasai: right 13:36:12 florian: do we want to specify step-back, or specify that you *can't* use a balancing that causes growth 13:36:16 fantasai: that's very complicated 13:36:35 florian: right, we ahd earlier text that said if rebalancing would move something to another line that changes the height, don't make that move 13:36:41 fantasai: that's complicated, don't think we want to do it 13:36:42 iank_: agree 13:37:09 astearns: i think the earlier restriction on balancing is we couldn't change the number of lines, and we relaxed that. not sure we ever had a restriction on height. 13:37:15 fantasai: okay i think we can take af ew resolution 13:37:33 fantasai: proposed: balancing happens after determining the clamp point for 'balance'. ('pretty' is up to the UA) 13:37:59 astearns: objections? 13:38:09 schenney has joined #css 13:38:10 RESOLVED: balancing happens after determining the clamp point for 'balance'. ('pretty' is up to the UA) 13:38:48 fantasai: second thing is if rebalancing causes the content to grow past the clamp point (for height clamping), you're allowed to step back and redo clamping a line earlier (but you can't step forward if balancing added more space) 13:39:03 fantasai: i think we should give discretion to the UA about how many cycles they have to do 13:39:15 s/fantasai/florian/ 13:39:32 fantasai: no, you can construct a case where stepping back continues to cause problems 13:39:50 florian: i think you can eventualky step back and *not* rebalance, that's better than rebalancing and overflowing 13:40:11 TabAtkins: I see, agree. Agree that avoiding overflow is the most important 13:40:58 fantasai: proposed: if rebalancing causes the content to grow and overflow, the UA *must* step back (clamping a line earlier), and *may* rebalance again, but *must not* overflow. 13:41:25 s/rebalance/rebalance (and possibly step back again)/ 13:41:26 florian: as many rounds as the UA wants, but at the point where they give up, the state must be not overflowing. 13:41:38 s/must not overflow/that rebalancing must not overflow/ I think? 13:41:45 astearns: objections? 13:42:16 RESOLVED: if rebalancing causes the content to grow and overflow, the UA *must* step back (clamping a line earlier), and *may* rebalance again (and possibly step back again), but *must* end in a state that doesn't overflow. 13:42:41 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10439 13:42:41 Topic: [css-overflow-4] How do `-webkit-line-clamp` and `line-clamp` interact when both are specified? 13:42:41 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10439. 13:43:01 andreubotella: usually when you have -webkit prefixes they're alias or legadcy shorthand 13:43:11 andreubotella: so there's always a way to replace the -webkit prefix with the modern one 13:43:18 andreubotella: even if the parsing is different 13:43:28 andreubotella: this is not the case for -webkit-line-clamp, due to web compat constraints 13:43:39 andreubotella: -webkit-line-clamp only works with -webkit-box and vertical on the same element 13:43:52 andreubotella: over 4% of page laods are using it wrong and we'd change their behavior if we changed this 13:43:59 andreubotella: so what happens if you set both on the same element? 13:44:14 andreubotella: currently they're both defined as shorthands over some longhands, including 'continue' 13:44:29 andreubotella: the keyword of 'continue' that triggers the legacy behavior is "continue: -webkit-discard" 13:44:38 andreubotella: and a similar "-webkit-collapse" 13:45:05 andreubotella: so if you ahve "line-clamp: 3; -webkit-line-clamp: 4", then "continue" will have -webkit-discard 13:45:17 q+ 13:45:19 andreubotella: so even tho the unprefixed version is set, it'll still require -webkit-box 13:45:24 andreubotella: do we want this behavior? 13:45:47 andreubotella: there's also the fact that in chromium this is only possible to implement if we actually have the longhands 13:46:14 andreubotella: but we've said the longhands must not be web-exposed currently. this would require changing chrome's property reoslution. not insurmountable, but I'd like to not do it, it's new territory 13:46:32 ack florian 13:46:46 q+ 13:46:46 florian: indeed, we say in the spec that this is defined in terms of shorthand/longhands, but dont' expose the longhands yet 13:47:06 florian: the intent when we did it wasn't that the longhands were wrong, but that we thought the shorthand was good and we wanted room to tweak the longhands 13:47:17 florian: but the interaction of th eprefixed and unprefixed do happen in the longhands 13:47:26 florian: so we either need to expose some interaction, or double down 13:48:01 florian: assuming we can get longhand to work, the situation that Andreu is concerned about is that you have both versions set, and the prefixed version is last in cascade, and you don't have the legacy special properties that make the legacy version work 13:48:23 florian: you start with line-clamp:3, then you add the -webkit-line-clamp one, and you lose clamping entirely 13:48:34 florian: i think that's ok? if you don't want it, don't have the legacy thing last on the cascade 13:48:52 florian: there are a bunch of websites that have the legacy and it works, and a bunch that have the legacy and it doesn't work and they need it to not work 13:49:09 florian: but at the point where you also have the new syntax, that's where you need to be careful. yo udon't add the new syntax with the intent that it doesn't work 13:49:20 florian: it's a little weird, but i think it's fine 13:49:39 florian: so do we want to double-down on the longhand syntax, do we really want non-exposed longhands, or do we want to change how we define this? 13:49:48 fantasai: it's comitting to the longhands ahving independent effects 13:50:00 fantasai: if you just specify max-lines and not the others, will that have an effect? 13:50:14 fantasai: i think we want to go there ultimately, whatever we decide ehre has to be compatible 13:50:20 fantasai: so we'd have to expose each longhadn 13:50:40 florian: if we think we want to go there but we're not ready, maybe go for private longhand version 13:50:47 ack emilio 13:51:07 emilio: it feels weird - it's unfortunate that we can't just make -webkit-line-clamp an alias, that sucks 13:51:11 s/it's comitting/it's not just committing to the syntax, but also / 13:51:32 emilio: but it feels like this should be implementable without having weird internal longhands, if we add the ability to specify the legacy behavior to 'line-clamp' 13:51:33 s/will that have an effect?/then that needs to have its intended effect/ 13:51:35 emilio: and that seems workable 13:51:47 emilio: that way -webkit-line-clamp would just be a shorthand of line-clamp in the interim 13:51:51 florian: i think that would work 13:51:57 emilio: that seems fairly easy to implement 13:52:08 emilio: prevents having two longhands that do different things that interact weirdly 13:52:23 emilio: it might be a keyword or something at the end of 'line-clamp', it causes the weird legacy stuff 13:52:27 +1 emilio 13:52:38 emilio: i think that's simpler and doesn't preclude us from breaking down line-calmp into shorthands in the future 13:52:41 florian: agree 13:52:43 +1 as well 13:53:16 andreubotella: i want to be careful that the syntax - in the utopian case where we can remove the legacy behavior, we want this legacy syntax to still work 13:53:27 andreubotella: that would still require implementing the legacy syntax in engines 13:53:44 emilio: that's the same as can we ever remove continue:-webkit-discard 13:53:52 ntim has joined #css 13:53:58 florian: either people are not using it anymore and we can remove it regardless of syntax, or they are using it and we can't remove it regardless of syntax 13:53:59 present+ 13:54:09 q+ to reply to fantasai 13:54:23 fantasai: is this flag actualy something in the syntax that an author can specify, or is it just something we store internally? it woudln't strictly round trip 13:54:31 ack emilio 13:54:31 emilio, you wanted to reply to fantasai 13:54:34 florian: think we can keep it simple, just slap a legacy keyword on it 13:54:49 emilio: yeah unless this is partiuclarly annoying, i think we should just add a keyword to the syntax so it round trips 13:55:02 emilio: too many things that iterate over properties and copy them, would be weird if that didn't work 13:55:10 emilio: so if you copied the computed display value... 13:55:13 q+ 13:55:19 emilio: display and line-clamp, it wouldn't work 13:55:28 emilio: you'd put a standard line-clamp on a -webkit-box 13:55:32 ack florian 13:55:39 florian: I suggest we just make the keyword sipmle and not magic 13:55:56 florian: there's no good reason for people to directly use it. it'll trigger from teh prefixed proeprty; people could write it themselves but why woudl they 13:56:16 florian: the only thing you get from this keyword is the requirement to also set these other stupid properties 13:56:21 TabAtkins: agree, we can just give it a dumb name 13:56:39 andreubotella: and make sure it's listed as deprecated in MDN to help push authors away 13:56:58 astearns: so if an author specifies line-clamp, then after specifies -webkit-line-clamp, it still won't clamp becuase the other properties aren't set 13:57:16 astearns: but the value of line-clamp is set to the legacy thing. we're just specifying the interaction and making it as normal as possible wrt the cascade 13:57:48 astearns: proposed resolution: Add a "legacy" value to line-clamp, and define -webkit-line-clamp to be a shorthand of line-clamp that adds the keyword 13:57:58 fantasai: can it be a -webkit prefix? make it ugly? 13:58:01 TabAtkins: yeah let's 13:58:04 -webkit-legacy 13:58:19 s/ugly/obviously linked to the -webkit- weirdness/ 13:58:35 astearns: objections? 13:58:51 RESOLVED: Add a "-webkit-legacy" value to line-clamp, and define -webkit-line-clamp to be a shorthand of line-clamp that adds the keyword 13:59:14 astearns: there's no problem with line-calmp resetting -webkit-line-clamp to its initial value? 13:59:18 florian: [shrugs] 13:59:56 fantasai: since line-calmp is a shorthand of continue, and in the longhandy version of this the weirdness is tied to a -webkit-* keyword... 14:00:08 florian: we're speccing two versions in parallel right now, a collapse and a discard 14:00:13 jensimmons has joined #css 14:00:14 florian: we're about to switch from discard to collapse 14:00:27 florian: jsut havent' decided it yet 14:00:42 fantasai: well my point was going to be to use that keyword name, since that's usually how keywords work, but sounds complicated. never mind 14:00:46 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10823 14:00:46 Topic: [css-overflow] interaction between text-overflow:ellipsis and line-clamp 14:00:46 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10823. 14:01:08 andreubotella: in chrome's impl of -webkit-line-clamp if you set text-overflow:ellipsis 14:01:19 andreubotella: that will not take effect 14:01:29 andreubotella: i'm not sure if webkit's behavior, originally or currently, works liek that 14:01:32 (there's no ellipsis) 14:01:33 q+ 14:01:47 andreubotella: the ellipsis defined by block-ellipsis is a different thing than text-overflow:ellipsis 14:02:06 andreubotella: block-ellipsis is specified to be placed at a soft-wrap opportunity 14:02:22 andreubotella: so with current spec text, text-overflow and block-overflow can apply to same element 14:02:48 andreubotella: so in chromium we're going to ship line-clamp without letting you specify a custom block ellipsis 14:02:58 andreubotella: this'll only really have an effect on the lines before the clamp point 14:02:58 Francis_Storr has joined #css 14:03:33 andreubotella: if you have a block-ellipsis set to a string, and it's a long string, longer than the line lenth, that interaction with clamping must be considered 14:03:47 andreubotella: the chromium impl currently has an impl of this, with block-ellipsis and breaking at soft wrap, behidn a flag 14:04:03 andreubotella: and that would not prevent text-overflow from also working on the same line 14:04:12 ack florian 14:04:27 florian: as a reminder, text-overflow:ellipsis, tho it also adds a ..., works super differently 14:04:33 florian: doesn't work on a block as a whole, it's on individual lines 14:04:47 florian: if a given line, after wrapping, overflows, it truncate sand visually places a ... 14:04:50 florian: no effect on layout 14:05:08 florian: lines after the last one (after clamp/balance/ellipse) and some lines above the clamp point overflow 14:05:14 florian: spec says to do the ellipsis on those 14:05:19 present+ 14:05:27 florian: i think theoreticaldly that's the right thing, but i think we don't really have a ton of use-cases for this 14:05:35 florian: i think text-overflow is best used on single-line things 14:05:46 florian: the things you use text-overflow:ellipsis on and line-calmp on are typically not the same 14:06:01 florian: so even tho they're specified to both work independently, if we said they can't work together, don't think i'd be sad 14:06:13 florian: second, for block-ellipsis with a long string, that might be long and overflow, then what 14:06:29 florian: spec currently says if the block-ellipsis overflow doesn't fit th eline, how you deal with *taht* is handled by text-overflow 14:06:42 florian: it gives you options for how to deal with the long ellipsis. makes sense in theory 14:06:45 q+ 14:06:48 jensimmons has joined #css 14:06:50 scribe+ 14:06:51 ack TabAtkins 14:07:05 TabAtkins: I don't understand what interaction is happening that makes line-clamp not work with text-overflow:ellipsis 14:07:12 florian: It could happen in theory, just not happening in practice 14:07:23 TabAtkins: what happens when you do have an extra-long line in a line-clamped container? 14:07:36 andreubotella: In current implementation, if this is not the last line, nothing happens and line overflows. 14:07:59 andreubotella: If it's the last line, currently all implementations currently behave the same as text-overflow:ellipsis, but not in my prototype 14:08:10 TabAtkins: That's odd and unfortunate. 14:08:20 TabAtkins: I really don't see why they're linked. Maybe some reason in implementation, but seems very strange. 14:08:41 TabAtkins: The one case that they should both work together is 
 is to have text-overflow to not be too long, and line-clamp to not be too long
14:08:51  q+
14:08:57  TabAtkins: having to choose between overflow down vs overflow to the side seems bad. IDK why we are adopting such a limitation
14:09:18  andreubotella: I don't know why that is the case. It was the case when I started working on line-clamp
14:09:36  andreubotella: I expect it's because initially the ellipsis for line-clamp was implemented the same way as text-ellipsis
14:09:44  andreubotella: I don't know why it wouldn't apply to other lines
14:10:00  ack fantasai
14:10:21  fantasai: i think i agree with TAb that it doesn't amke sense for these to be interacting. text-overflow just applies after you do all the line-clamp stuff, makes sense
14:10:49  fantasai: it seems reasonble that if the -webkit-overflow did their ellipsis with the text-overflow mechanism, it doesn't work. makes sense as an accciendtal limitation
14:10:51  ack florian
14:11:11  florian: the early ipml was quick and dirty, it used and abused all sorts of parts. that's almost certainly why you can't do both at the same time.
14:11:20  florian: my hope is to keep the spec as it is, hope browsers fix it.
14:11:32  florian: Hopefuly the interaction is rare enough that even if browsers dont' get it right currently that's okay
14:11:43  astearns: and the spec currently says you do both?
14:11:43  florian:
14:11:46  astearns: is there an ordering?
14:12:03  florian: yeah they're independent. after everything else, if some individual lines overflow, you text-overflow ellipsize them
14:12:20  andreubotella: yeah, spec says after everything is done, if a line overflows it's handled by text-overflow
14:12:25  astearns: so closing this issue no change?
14:12:35  florian: i think so. is that okay, Andreu?
14:12:44  andreubotella: yeah, i don't have a problem with that
14:12:47  astearns: objections?
14:13:00  RESOLVED: Close no change (text-overflow shoudl work as normal in line-calmp containers)
14:13:09  Topic: [css-overflow-4] Should abspos painting in line-clamp depend only on whether the containing block is before clamp?
14:13:33  andreubotella: we previously resolved on abspos wrt compat behavior
14:13:40  andreubotella: in #11379
14:13:52  andreubotella: we show all abspos whose CB is the line-calmp container or a predecessor
14:14:04  andreubotella: we never resolved o nwhat to do for abspos whose CB is a descendant of the line-clamp container
14:14:12  andreubotella: we'd discussed it, just never resolved
14:14:33  andreubotella: when i was working on chrome impl, tests, and spec pr, i was trying to get as close to continue:discard as possible
14:14:48  andreubotella: and in that, if the CB is in a discarded fragment, the abspos wouldn't show up
14:15:08  andreubotella: so the behavior i'm ipmlementing is the abspos is hidden if its static position is below the clamp point
14:15:27  andreubotella: but Ian had a differetn udnerstanding, that an abspos is hidden if and only if its CB is fully below the clamp
14:15:40  andreubotella: that includes the previous resolution, and is also simpler to implement in chromium
14:15:54  q+
14:15:54  q+
14:16:00  andreubotella: it's less similar to continue:discard, but considering we're dealing with webcompat i think it makes sense
14:16:01  ack florian
14:16:05  florian: making sure i understand
14:16:09  dholbert has joined #css
14:16:20  florian: in both cases, we're talking only about abspos whose CB is a descendant of the clamp container
14:16:23  florian: other cases are handled already
14:16:38  florian: so q is if we hide the abpsos when its CB is after the clamp point, or static position is after
14:16:48  florian: if CB is after the clamp point, its static position is necessarily after too
14:16:54  florian: but reverse isn't necessarily true
14:17:08  ack emilio
14:17:08  florian: CB might be (partially) above the clamp, but static posiition is after. that's the case, yeah?
14:17:10  andreubotella: correct
14:17:25  emilio: if the CB is another abspos that's already out of the question
14:17:32  emilio: so this is only if the CB is in-flow
14:17:51  emilio: if it's in-flow, proposal is that if the in-flow is completely clamped, you don't paint the abspos, otherwise you do
14:17:53  emilio: that seems sensible to me
14:17:54  ack fantasai
14:18:09  q+
14:18:45  florian: so in andreu's initial, if the CB was partially in and partially out, but the staticpos was out, you suppress
14:19:01  florian: but now if the CB is partialy in and partially out, you always paint the abspos
14:19:04  ack iank_
14:19:15  fantasai: yeah, don't thinkwe should depend on static position unless it's staically positioned
14:19:23  iank_: i think we should indeed use this simple thing
14:19:30  iank_: removing static position is trivial, shoudln't depend on it
14:19:47  iank_: and anchorpos can depend on entirely differnt things, not caring about static poisition at all. shouldn't try and depend on that
14:19:48  ack fantasai
14:19:59  fantasai: thinking about pagination, more interesting
14:20:30  fantasai: if doing some regions things, abspos containing block on second page with an abspos that positioned itself really far up, impls struggly with that. can't move to a previous page very well, but can push to next page
14:20:43  fantasai: so there's an inconsistency in pagination today. hope someday we can fix
14:20:56  thats not strictly true for chromium's implementation.
14:20:58  fantasai: but for this case, i think it's reasonable to do a simpler appraoch - if something is discarded
14:21:14  florian: i think i largely agree, but in pagaintion i'm not clear this behavior is wholely wrong
14:21:27  florian: moving an abspos back to earlier pages when the CB is paginated should get right
14:21:40  florian: but if the CB is an inline on a later page, less convicned it's worthwhile to move to an earlier page
14:21:46  astearns: sounds like we ahve a resolution for this particular case
14:21:55  I think drawing outside the fragmentation container is wrong
14:22:17  andreubotella: proposed: an abspos is hidden if and only if its CB is fully after the clamp point
14:22:38  TabAtkins: IIRC, we do have the geometry of everything after the clamp point?
14:22:43  andreubotella:
14:22:45  andreubotella: yep
14:22:51  TabAtkins: So well-defined what the position of things is
14:23:06  andreubotella: but I wouldn't be sure that's true for 'continue: discard'
14:23:14  astearns: objections?
14:23:32  RESOLVED: An abspos is hidden by line-clamp only if its CB is fully below the clamp point
14:23:40  andreubotella: should this also apply to fixpos?
14:23:52  iank_: yeah they're the same
14:24:35  iank_: if there's a transformed ancestor, it's jsut a normal abspos
14:24:50  github-bot, end topic
14:24:56  

14:49:29  alisonmaher has joined #css
14:49:40  github-bot, take up https://github.com/w3c/csswg-drafts/issues/10868
14:49:40  Topic: [css-overflow] What counts as "immediately preceding" for `block-ellipsis`?
14:49:40  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10868.
14:50:11  florian: if you're line-calmping pure text it's easy, but there are things that aren't lines, like a block image
14:50:20  florian: so an interseting set of questions, maybe the asnwer is the same when you clamp by line count vs height, but...
14:50:29  florian: say you have 3 lines of text, several blockified images, then a fourth lines
14:50:40  florian: if you say line-clamp:4, you clamp after 4 lines, easy
14:51:02  florian: if you say line-clamp:4 but there's not room for all four, just three lines + some images, do you stop after the last line of text, o rkeep everythingg that fits
14:51:17  florian: same question if you clamped by height, and that line ends after a few of the images
14:51:34  florian: a possible answer is you stop after the last line that fits, everything else is dropped even if you have room for it
14:51:44  florian: another is you keep the extra content, but then where do you put the ellipsis?
14:51:58  florian: on the alst line of text that fits even tho it's well above the cu tpoint?
14:52:15  florian:  or just dont' do an ellipsis, since the last thing beofre the break isn't a line?
14:52:24  florian: do we want the same answer for count and height clamping? or different?
14:52:39  florian: i think that's the full problem space. we got the questions thru thinking about this issue
14:52:47  florian: i think it would be unfortunate to have room for more content and not dipslay it
14:52:56  florian: i have a mild preference for displaying the images, and not having ellipsis
14:53:09  florian: I think Tab would prefer the ellipsis on the last line of text, followed by images
14:53:17  florian: as it still tells you there's more to come
14:53:18  ack dbaron
14:53:38  dbaron: I think I mostly agree with your preferences, with the caveat i don't really care about the ellipsis itself
14:53:42  dbaron: but agree about showing content that fits
14:54:04  dbaron: question is in the case where you're counting lines, does it make sense to count block images as lines rather than pretend they don't exist? or is there a reason not to?
14:54:23  florian: we started from just counting lines as lines, didn't think further. don't think that solves the problem entirely.
14:54:36  iank_: there's a small reason to keep them separated to just count lines
14:54:58  iank_: block level images, eh, but imagine you have block content at the start of the cdontext, then say line-clamp:3, it would be surprising if you had the image and then just two lines
14:55:08  iank_: so i do think you just want to count actual lines
14:55:14  ack fantasai
14:55:23  fantasai: agree with preferenc e to show ccontent if there's space
14:55:34  fantasai: question about where to put ellipsis is interesting
14:55:35  fantasai: what does the spec say if there's no lines/
14:55:40  florian: i htink you don't put it
14:55:44  andreubotella: yes
14:56:07  q+
14:56:12  q+
14:56:37  andreubotella: current spec is based on continue:discard, it says the block-overflow ellipsis is..... can't find it righ tnow. it says it's immediatley before a region break or the clamp point. if there is no line, there's nothing
14:56:55  florian: a bit more detail, the block-ellipsis longhand property doesn't apply to the clamping container, it applies to block containers
14:57:10  florian: wherever your clamp point ends up being, if it's in the middle of a block element, it inserts the ellipsis on *its* final line.
14:57:16  florian: and if there's no line, no ellipsis
14:57:20  fantasai: i think that makes sense
14:57:32  fantasai: so i think it makes sense to not insert the ellipsis unless we're clamping right before the line
14:57:55  fantasai: think it woudl also be a bit misleading if the paragraph had the ellipsis right before the images, it looks like the paragraph isn't completed
14:58:31  astearns: i think the ellpsis is an important part of the feature. to ensure we're always displaying the ellipsis in a place that makes sense, i'd be happy to discard the block content after the ellipsis to prioritize showing the ellipsis
14:58:38  astearns: but this is an edge case, don't strongly care
14:59:04  florian: another variant is we could say that, once you're dsicard remaining contents, if the last thing doesn't have lines, you insert one more line just for the ellipsis, and if that doesn't fit you remove until it does
14:59:20  florian: so if cut point allowed three lines and two images, you remove the second image and put in a line with the ...
14:59:42  astearns: so if there's only one block-level image before the clamp point, we woudln't display the image, the ellipsis would be on a separate line below the last actual line
14:59:51  q+
14:59:54  astearns: it might be too complicated or such an edge case, but i think i would prefer it to the other options
14:59:55  ack astearns
15:00:24  iank_: i think we agreed previously that the line-clamp:auto case should behave the same as specifying the number of lines clamped
15:00:29  iank_: and this seems to be going against that
15:00:36  iank_: i think i have a preference of hiding the content after the clamped line
15:00:37  q+
15:00:41  iank_: for consistency
15:00:43  ack iank_
15:01:00  iank_: and it feels more consistent that if there's a ... there's more content. having content after that feels wrong to me
15:01:15  iank_: don't think we should have a line that just containts an ellipsis, suspect we'd get bug reports on that
15:01:32  florian: i think if you have line-clamp:3 you should get three lines, not 3 lines and some images
15:01:48  iank_: right, i think we have some discussion about that
15:01:53  florian: no reoslution
15:02:11  ack andreubotella
15:02:24  andreubotella: so we're talkinga bout block images, but it's not just that. if you have an IC, a block with a height but no lines, these are also cases where this would happen
15:02:38  andreubotella: so i'm unsure if it's as edge-casey as we might otherwise think
15:02:50  andreubotella: only block images, sure, but with all these other options seems more common, a table or something
15:03:02  ack TabAtkins
15:03:07  s/IC/independent formatting context/
15:03:36  TabAtkins: Big thing I want to be consistent with, is that we should not be giving 'auto' to produce behavior that cannot be produced with an integer
15:03:45  TabAtkins: that doesn't necessarily mean that 'auto' behavior Florian wants is wrong
15:04:08  sorry
15:04:09  TabAtkins: whether that's something we do turn on for an integer clamp, e.g. if you clamp to 4 lines, we should show 3 lines of text and following images
15:04:21  TabAtkins: and maybe add a keyword to show whatever still fits
15:04:28  TabAtkins: Either works for me
15:04:35  TabAtkins: Because they produce consistent behavior between the two pieces
15:04:48  TabAtkins: I just don't want 'auto' to have a different behavior not tied to concept of a height clamp
15:05:40  so like `line-clamp: 3 and-then-some;` to mean "3 lines, and whatever else non-line content sitll fits after the third line"
15:05:54  florian: In case where you clamp by line number
15:06:15  florian: and then adding extra
15:06:24  florian: how do you determine more stuff?
15:06:42  [something baout 3 lines and 1000px ]
15:07:15  TabAtkins: auto means some specific line clamp value, just auto-clamped for you. You don't get a magic behavior, it's a calculation that turns into a describable behavior
15:07:30  florian: So line-clamp: 3 magic
15:07:31  I am not sure the difference in behavior is something authors will want to choose between. We can probably just choose one thing (and wait to see if people need the other)
15:07:37  florian: You get 3 lines plus however non-line things fit
15:07:50  ack fantasai
15:07:50  fantasai, you wanted to flip Tab's argument
15:08:04  fantasai: what property is this "auto" value on?
15:08:23  dholbert has joined #css
15:08:38  andreubotella: it's in the  production (which is in line-clamp shorthand)
15:09:06  fantasai: so we don't actually ahve line-clamp with amgic keywords
15:09:15  fantasai: we have 'continue', we have 'height', we have 'max-lines'
15:09:25  fantasai: max-lines says the intrinsic height is what you get after N lines
15:09:34  fantasai: so if you set max-lines it doesn't cause clamping
15:09:53  TabAtkins: in the thoertical world where these are separate longhands, sure
15:10:13  florian: if you set line-clamp to some value that doesn't have an integer, these expand to the block-ellipsis property, and turns on the correct 'continue value
15:10:37  florian: but becuase you don't have a strict number of lines, in continue:discard you discard when you'd start to overflow...
15:10:47  fantasai: lets go back. there's no magic auto keyword
15:10:56  fantasai: all block-ellipsis does is set the ellipsis, we can ignore it
15:11:21  fantasai: i want to flip tab's argument in the other direction. tab is saying we should describe all behavior in terms of clamping lines, i'm saying we should describe in terms of height, and you clamp to that height.
15:11:42  fantasai: so clamping to a specified height is not a special case of clamping to a number of lines, clamping to lines is a special case of clamping to a magically determined height
15:11:55  fantasai: so i don't think we need to turn height-based clamping into some kind of line-based clamping, that doesn't make snese
15:12:22  astearns: i think a consequence of your conception is that a height clamp *will* contain block-level things, but a line clamp won't
15:12:32  fantasai: right
15:12:42  that makes sense to me
15:12:47  florian: and line clamp gives you a different height where things after the line doens't fit
15:13:07  i've got to drop
15:13:12  fantasai: but if you have no fourth line, you say line-clamp:4 and don't have four lines, you just show everything
15:13:28  smfr has joined #css
15:13:35  +1
15:13:44  TabAtkins: Sounds reasonable to me
15:14:01  TabAtkins: is it currently the case in the spec, given our example, if you set line-clamp: 4 you get all the content without a clamp because the ...
15:14:07  TabAtkins: if you have line-clamp: 4 and a fixed height
15:14:35  fantasai: what you're setting is max-lines:4, and height:1000px, and you clamp at whichever comes first
15:14:47  andreubotella: Implementation-wise that is more complicated
15:14:48  andreubotella: impl-wise i think it's more complex
15:14:57  andreubotella: it depends on a number of factors
15:15:05  q+
15:15:31  andreubotella: currently in my impl, if you set both max-height and line-clamp:4, then max-lines takes priority because it's easier to deal with
15:15:51  andreubotella: so it's not impossible we could do the other way and clamp to whichever comes earlier
15:16:06  andreubotella: and if we ahve "line-clamp: 3 plus-more" that would solve some other
15:16:22  ack florian
15:16:38  florian: what elika described is how we described "continue:discard" to work, and i like that
15:16:51  florian: not sure how that works in "continue:collapse", it's not purely height bsaed
15:17:22  florian: if you have decorated box with 5 lines and some borders, and you say clamp:3, you dont cut after that third line, you have the borders as well. so height is more than just the three lines height
15:17:39  florian: so line-clamp:N isn't exactly clamping after the height of N lines
15:17:51  andreubotella: well there is a height that would let you calmp after N lines, it just also depends on MBP
15:18:12  astearns: putting aside ellipsis, can we resolve that a height clamp will show trailing block-level things that fit, but a line clamp stops at the last line
15:19:11  TabAtkins: Possibly implies that line-clamp: 4 would clamp to 3 lines if that's all that would fit
15:19:26  florian: andreu, remind me what happens if you have line-clamp:N and a height?
15:19:39  andreubotella: if you have both, only number of lines matters in my impl
15:19:49  andreubotella: we could change to make it whichever comes first
15:19:59  andreubotella: but would be difficult to implement
15:20:08  TabAtkins: So if 4th line is overflowing, we would just overflow the box?
15:20:15  andreubotella: yes
15:20:37  astearns: so can we resolve on this now?
15:20:48  fantasai: yes, and the question of what happens hwen you have both a line and height clamp can be separate
15:20:51  astearns: objections?
15:21:21  RESOLVED: when doing a height-based clamp, content after the last fitting line but within the height still gets displayed. a line-based clamp clamps after the clamped line
15:21:53  (applying both simultaneously tbd)
15:22:00  florian: so next question, if the last thing that fits before the calmp point isn't a line, do we (as currently specced) not have an ellipsis, or do we want an ellipsis somewhere?
15:22:17  astearns: for all that i prioritized dislay of ellpsis in my mind, the options are icky. so i'm happy to leave the spec as is
15:22:26  TabAtkins: I'm weakly for putting on last line that's visible
15:22:30  TabAtkins: but ok to go the other way
15:22:45  astearns: objections?
15:23:00  fantasai: think it's reasonable. if authors complain we can reconsider
15:23:21  RESOLVED: Leave the spec as-is wrt ellipsis when the last thing before the clamp isn't a line. (aka don't draw the ellipsis in this case)
15:24:10  github-bot, take up https://github.com/w3c/csswg-drafts/issues/7708
15:24:10  Topic: [css-overflow] Is continue: discard working in the fragment tree useful?
15:24:10  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7708.
15:24:20  florian: avoiding the big discussion without ian, but a small topic
15:24:33  florian: right now spec is defined in terms of continue:discard, and there's a sketch of continue:collapse
15:24:44  florian: we could invert that, and say line-clamp shorthand triggers the collapse behavior
15:25:02  florian: it seems clear to me at this point that the thing we're shipping in the short term is collapse-based, not discard-based
15:25:23  florian: the broader spec should still talk about discard because i think it's good, but if you don't ask (because the shorthand doesn't le tyou specify currently), you shoudl get collapse
15:25:29  florian: anything further we should wait for Ian
15:25:43  andreubotella: i added this back in October, not sure what I wanted to get out of it. but i'm fine with that
15:26:01  andreubotella: there are a number of points for continue:collapse/discard that it would be good to touch on to make sure everyone agrees, but can happen later
15:26:13  andreubotella: like the issue we touched on earlier about bottom MBP
15:26:42  andreubotella: but we can resolve for now that line-clamp does continue:collapse
15:27:15  andreubotella: later i expect to have the patch and PR up ready to merge
15:27:56  florian: i continue to think that continue:discard is a better model, but i accept that continue:collapse is sufficiently useful (and sufficinetly simple) that it's going to ship. no use pretending we're going to do what we're not going to do
15:28:13  florian: think there's a lot of discussion in this big issue, but they should be split out. so let's just agree that the default is "collapse" for now
15:28:30  astearns: so proposal is to rework the spec so line-clamp defaults to collapse behavior, and open separate issues on everything else
15:28:31  florian:
15:28:34  florian: yes
15:28:36  andreubotella: yes
15:28:39  astearns: objections?
15:28:56  RESOLVED: change the line-clamp default to continue:collapse, split out further questions into separate issues
15:29:37  github-bot, take up https://github.com/w3c/csswg-drafts/issues/11802
15:29:37  Topic: [css-overflow-5] scroll-marker-group on root scroller?
15:29:37  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11802.
15:29:56  flackr: we defined how ::scroll-marker worked for overflow:scroll conktinaers
15:30:33  flackr: Question on whether to apply to the root element
15:30:41  flackr: This makes sense, but would require a slight change in behavior
15:31:03  florian: with overflow scrollers, the layout box for the scroll marker group is outside the scrolling container
15:31:09  s/florian/flackr/
15:31:14  flackr: but theres' nothing outside the root scroller
15:31:29  flackr: so the beahvior would be that they're like ::before or ::after on the root, before/after the first/last child
15:31:39  flackr: so they would be moved by scrolls unless you used fixpos to prevent that
15:31:45  flackr: otherwise everything works the same
15:31:56  astearns: that sounds reasonable, but do we have to?
15:32:10  flackr: many sites like usign the root scrolling because it works better with the address bar.
15:32:21  flackr: and you can create ToC-like thing with scroll markers
15:32:41  q+
15:32:46  astearns: makes sense, i just hadn't seen a description fo th euse-case
15:32:47  ack emilio
15:33:02  emilio: why can't it be a sibling? some things like top layer are alreayd defined to be like siblings of the root
15:33:30  flackr: it couldn't reserve space in a way taht meaningfully interacts with the scorlling content...
15:33:36  flackr: but we could psoition is similar to top-layer items
15:33:45  flackr: i think i'd find it a bit surprising, but...
15:33:51  flackr: i'd rather have authors treat them as fixpos
15:33:58  emilio: a fixpos element is not within the scroller either
15:34:08  emilio: so i'm not sure why making them a fixpos element wouldn't work
15:34:19  flackr: that's what i'm proposing authors do - make them fixpos
15:34:32  emilio: do we need to make themc hildren, tho? why the exception?
15:34:40  flackr: there are implications with how you navigate thru focusable content
15:35:01  flackr: like scroll-marker-gorup:after focuses after the scroller content. making it last child works naturally
15:35:09  flackr: but i suppose it could be defined to work like that
15:35:19  emilio: right, you need to define that for top-layer things anyway.
15:35:28  emilio: VTs are siblings of the root but they're not focusable
15:35:38  flackr: and i don't think it maeks sense to be implicitly on top of all the content
15:35:43  emilio: they don't need to be?
15:35:50  flackr: then i don't understand the behavior proposal
15:36:05  emilio: do these inherit from their originating element even tho they're siblings?
15:36:07  flackr: yesah
15:36:13  emilio: then i guess it doesn't really matter too much
15:36:24  emilio: difference is if they're statically possitioned, they're inside or outside the root scroller
15:36:35  emilio: i was just a bit conderned about inheritance, but i guess that doesn't change
15:36:44  emilio: so i just wonder when this would be observable
15:36:54  emilio: so only if they're statically positioned
15:37:02  flackr: yeah, they'd act like the first/last children of the document
15:37:28  emilio: i guess if that difference would be useful... i guess id on't object to making them children
15:37:44  emilio: at least DOM-wise i don't see a need for the exception, but it's useful to not ahve in-flow content outside the root scroller
15:37:44  q+
15:37:57  flackr: yeah, i'm thinking it would be less of a special case
15:37:58  ack TabAtkins
15:38:29  TabAtkins: One question. How difficult would this make it to, say, put your scroll group in one cell of a page-defining grid, and the rest of your content in the other cell of the grid?
15:38:36  TabAtkins: e.g. if you wanted to set up a table-of-contents
15:39:02  flackr: I think it could participate in the grid established by the root element...
15:39:11  q+
15:39:20  ack emilio
15:39:27  emilio: yeah i guess that's a case where making it a sibling of the root would be annoying
15:39:49  fantasai: wouldn't that be consistent with the *toher* cases tho?
15:40:05  fantasai: and do we really want to develop scroll markers to the point where they can be a full ToC?
15:40:10  TabAtkins: they're already pretty much there
15:40:19  flackr: there's also cases already for full-page carousel dots
15:40:24  s/toher/other/
15:40:41  fantasai: i guess you do still have access to the body as a wrapper
15:40:57  s/body/parent/
15:40:58  flackr: yeah, if it's a sibling of root you don't ahve access to the overall container
15:41:21  astearns: so proposed is that scroll-marker-group on the root is treated as being a child of the root instead of a sibling
15:41:28  fantasai: taking tab's example of making a page grid
15:41:44  fantasai: and the rest of the content was in the main section of the grid, markers in the side
15:41:57  fantasai: in that case the scrolling element is no longer the root scroller, which is kinda what you want, isn't it
15:42:06  fantasai: you still want the page to scroll via the root scroller
15:42:22  fantasai: so this might tie into another issue - can the page propagate its root scroller
15:42:40  flackr: i think the way it works is you just end up with a really tall grid, so you're still scrolling
15:43:01  fantasai: but then since it's not the root scroller why not set the grid o nthe html element, and make the body your scroll container
15:43:27  TabAtkins: [discuss example]
15:44:04  fantasai: so html is a big grid, body in the right slot, scroll-marker-group on the left slot, overflow:scroll on the body
15:44:11  flackr: skip the overflow-scroll, just let the grid get big
15:44:26  fantasai: but then your marker group scrolls off the screen
15:44:34  TabAtkins: then you use stickypos
15:44:50  astearns: does your qeustion modify the resolution we were tying to take?
15:44:53  fantasai: not sure. probably not?
15:45:12  TabAtkins: we definitely still want to address the scroll delegation, but not required to do reasonable things here
15:45:24  astearns: so again, any objections?\
15:45:59  RESOLVED: allow ::scroll-marker-group on the root, except it's a child of the root (first or last)
15:46:09  TabAtkins: is this inside or outside the ::before/after pseudos?
15:46:19  flackr: prefer outside, that's more consistent with the other cases where it's a sibling
15:46:27  github-bot, take up https://github.com/w3c/csswg-drafts/issues/11746
15:46:27  Topic: [css-overflow-5] ::scroll-marker should determine inherited interactivity from ::scroll-marker-group
15:46:27  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11746.
15:46:57  flackr: the a11y guidelines for carousel recommend inerting content that's not on screen
15:47:13  flackr: but if you inert the element that establishes the smarker, th emarker appears in a different spot
15:47:29  flackr: we think the interactivity of the scroll marker shoulod be based on the interactivey of the scroll-marker-group, which is based on the scroll container
15:47:50  flackr: currently authors *could* work aorund this by manually un-inerting with 'interactivity', but it feels like a hack. we should do this implicitly
15:47:51  +1
15:48:33  astearns: so resolution is interactivity of ::scroll-marker is based on interactivity of ::scroll-marker-group
15:48:36  astearns: objections?
15:48:44  RESOLVED: interactivity of ::scroll-marker is based on interactivity of ::scroll-marker-group
15:48:55  fantasai: there's a comment in the issue about visibility too
15:49:09  flackr: i'm open to doing this with more properties, but maybe we take those as separate resolutions
15:49:35  TabAtkins: visibility also doesn't have same issue as interactivity, no a11y recommendations
15:49:44  TabAtkins: if doing visibility it's up to you to manage
15:50:00  fantasai: so ::scroll-marker originates from the element that generates it, correct?
15:50:02  castastrophe has joined #css
15:50:11  fantasai: but in the box tree it's a child of ::scroll-marker-group
15:50:15  fantasai: where does it inherit from?
15:50:20  flackr: its originating element
15:50:36  fantasai: i think that's part of the confusion here. seems author would probably want it inheriting from scroll-marker-group
15:51:04  flackr: there are some... it's useful to inherit ccustom properties from the target to set styles or content on the marker
15:51:08  flackr: so it's a bit of a mix
15:51:17  present+
15:51:30  TabAtkins: when we support scroll markers that are real elements, much harder to change their inheritance patterns
15:52:02  florian: so if you set 'color' on ::scroll-marker-group, that doesn't change the color on the ::scroll-markers inside of it, which is a bit surprising
15:52:07  s/florian/fantasai/
15:52:17  fantasai: they'll get their color from their in-flow parent instead
15:52:36  flackr: when we have real-element scroll markers, they *will* be children of the group
15:52:50  flackr: there are just a lot of use-cases where it's useful to refer to properties in what it's pointing to
15:53:30  fantasai: is it only custom properties? if you set font on scroll-marker-group it doesn't inherit to the markers. if you generate markers from headings and some have various text styles, they'll get a random mix.
15:54:01  flackr: i suppose inheriting a counter is useful. you don't always want them to be counted separately
15:54:26  fantasai: i think properties hsould inherit from the scroll-marker-group, but originating element is still the target element, so attr() or counter() returns the value from that element
15:54:44  astearns: i think this is something we should consider, but not sure we'll get to a resolution on changing that today
15:55:03  flackr: does it make sense to resolve on interactivity, and have an issue on inheritance generally?
15:55:14  astearns: yes, people not in the room that probably have opinions
15:55:18  flackr: i'll file an issue
15:55:40  Topic: [css-overflow-5] Enforce layout containment on ::scroll-marker-group
15:56:07  flackr: we're proposing to enforce layout containment on scorll-marker-group. it avoids a lot of complex situations
15:56:18  PaulG3 has joined #css
15:56:22  flackr: like having intruding flaots, or abspos on a scroll marker resulting in it not being in the group
15:56:34  flackr: doesn't seem like there's a strong use-case to *not* have layout containment
15:56:38  PaulG has joined #css
15:56:54  flackr: and just less surprising in general to have it
15:56:55  TabAtkins: we already partially relaxed the size containment, right?
15:56:59  flackr: yup
15:57:16  astearns: only reason to not do it that i can think of is it's just yet anohter thing that changes the value of properties wihtout being explicitly set
15:57:18  astearns: sometimes hard to teach
15:57:31  flackr: i think we can set this in the UA style for ::scroll-marker-group
15:57:36  fantasai: would that be !important
15:57:42  flackr: yes
15:57:46  TabAtkins: and would then show up in devtools
15:58:01  astearns: so proposal is we set size containment for scorll-marker-groups as !important in the UA sheet
15:58:21  RESOLVED: ::scroll-marker-group gainst "contain: layout !important" in the UA style sheet
15:58:31  github-bot, take up https://github.com/w3c/csswg-drafts/issues/11600
15:58:31  Topic: [css-overflow-5] Making ::scroll-marker existence unconditional?
15:58:31  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11600.
15:59:05  TabAtkins: Currently per spec, the existence of ::scroll-marker-group is dependent on container having a non-none value for scroll-marker-group property
15:59:26  TabAtkins: The ::scroll-marker pseudos are dependent on their ::scroll-marker-group existing
15:59:57  https://drafts.csswg.org/selectors/#has-allowed-pseudo-element
16:00:29  TabAtkins: This means existence of ::scroll-marker is style-dependent, so can't appear as argument of :has()
16:00:45  TabAtkins: that's problematic
16:01:14  TabAtkins: e.g. Adam Argyle wanted to mark ::scroll-marker based on whether before or after current
16:01:20  q+
16:01:43  TabAtkins: My proposal is that scroll-markers always exist, they just don't generate boxes unless various conditions are met
16:01:47  +1
16:01:51  TabAtkins: that way you can always test whether scroll marker pseudo
16:01:53  dholbert has joined #css
16:02:09  TabAtkins: in :has() because it's always there
16:02:10  (I wonder if we should rename the "has-allowed pseudo-element" term to instead use words that describe the characteristic that makes the pseudo-element allowed within has.)
16:02:17  ack emilio
16:02:19  (i'm fine with a rename)
16:02:34  emilio: Wasn't super clear to me if this is intended to change existence of ::scroll-marker-group
16:02:49  TabAtkins: I don't have a strong opinion on that. don't think there's a need to check :has there
16:02:53  +1 dbaron, we should make it look less like a different pseudo
16:03:01  TabAtkins: but if we want to make things box-dependent ...
16:03:12  emilio: Also, why aren't we setting the pseudo-class on the originating element instead?
16:03:19  emilio: That seems simpler, less performance concerns.
16:03:38  emilio: We don't want to generate these, so I'd rather not... If we can apply to the pseudo-class to the originating element that's better
16:03:49  TabAtkins: That would solve this use case, and any case we care about
16:04:05  TabAtkins: Rob, did you have a reason why we can't set :target-current on the element?
16:04:20  flackr: What is :target-current depends on set of things that are ?? targets
16:04:27  s/??/eligible/
16:04:31  flackr: Something can be :target-current if it's the closest thing to the scrollport
16:04:41  flackr: but if there is another potential target, then that thing would be :target-current instead
16:04:57  flackr: So idk how you'd define that to work on regular elements without knowing whether they are targets
16:05:05  flackr: A thing becomes a target by having a scroll-marker
16:05:11  emilio: Doesn't that make it trivially cyclic?
16:05:30  emilio: If you can set a:has(::scroll-marker)::scroll-marker { display: none; }
16:05:36  flackr: yeah, that would be cyclic
16:05:40  TabAtkins: by definition
16:05:56  s/display:/content:/
16:05:58  TabAtkins: I'm trying to avoid that situation by generating the element by virtue of it being a link
16:06:17  flackr: Targets aren't links, they're htings you're linking to. Can be any element
16:06:38  emilio: [missed]
16:06:43  s/aren't links/aren't necessarily links/
16:06:46  emilio: That pseudo-class also depends on styles
16:07:00  flackr: Yes, because determining current target depends on which things are targets which is based on style
16:07:05  flackr: Maybe this is just something that we cna't allow
16:07:34  TabAtkins: Seems like :target-current is cyclic and can't be allowed in :has()
16:07:49  TabAtkins: Right now restricted because currently only allowed on the pseudo-element
16:08:03  fantasai: It's also allowed on regular element
16:08:13  fantasai: That's one of the core features of this spec!
16:08:22  flackr: For those cases I don't think it's trivially cyclic
16:08:33  ack fantasai
16:08:42  fantasai: I think the use-case should be solved
16:08:47  fantasai: by ahving more pseudo-classes
16:08:57  fantasai: :target-current, :target-past, :target-future
16:09:17  TabAtkins: I wanted to solve use case in a straightforward way
16:09:24  fantasai: The proposed solution is not straightforward...
16:09:33  astearns: so we'll take this back to the issue
16:09:36  present-
16:09:43  s/:target-future/:target-future, so we could solve this use case more directly/
16:09:47  github-bot, end topic:
16:09:47  TabAtkins, Sorry, I don't understand that command.  Try 'help'.
16:09:53  github-bot, end topic
16:09:59  

16:22:13  ydaniv has joined #css
16:49:18  emeyer has joined #css
17:09:41  we are working on probable AV issues. I assume remote folks are not getting audio or a bunch of mic tapping noises?
17:12:19  scribenick: kbabbitt
17:12:42  github-bot, take up https://github.com/w3c/csswg-drafts/issues/9091
17:12:42  Topic: [css-pseudo-4] Add a pseudo-element to style all highlight pseudo-elements
17:12:42  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9091.
17:12:58  schenney: context: the custom highlight api and css styling
17:13:05  ... each highlight has an ident and a style in css
17:13:16  ... and when you use the JS api to add that highlight ident to a range
17:13:20  ... everything in that range gets that style
17:13:28  ... this issue was raised in relation to custom props
17:13:31  .. subsequent changes made that go away
17:13:42  ... but it's sitll that if you want to apply certain props to all custom highlights
17:13:43  alisonmaher has joined #css
17:13:50  ... you need to repeat for every identifier in your JS
17:14:03  ... proposal is to have a special * identifier in CSS so that you can have ::highlight[*]
17:14:10  ... which would supplyu props to all custom highlights in the page
17:14:25  ... use case: underline type for all custom highlights but each ident might have a different color
17:14:31  ... was specifically raised in the issue
17:14:46  ... another use case is if you did in CSS highlight * and give it a bunch of props
17:14:53  .. then could register different IDs in JS
17:15:01  ... and they would all get highlighting from the * highlight
17:15:11  ... that would allow diff idents in JS to represent different ranges
17:15:23  ... I think this is totally reasonable, and implemented, and would address some developer pain points
17:15:45  ... one question: how exactly we deal with the case where there is both * matching all highlight props and a specific ident with a conflicting property
17:15:48  ... how to resolve?
17:15:53  ... thoughts?
17:15:57  q+
17:16:05  ack TabAtkins
17:16:10  TabAtkins: for the 2nd quiestion of opposing styles
17:16:21  ... what seems bvious to me is to do this at style resolution time
17:16:26  ... but that's not how you described it here
17:16:34  q+
17:16:39  ... spelling highlight would receive highlight spelling style since it's more specific than hoghlight *
17:16:54  ... both rules apply to spelling element same as if you had 2 spelling rules with contradictory styles
17:16:59  schenney: that's the way I understood it
17:17:06  ... bramus put in comments implying what TabAtkins just said
17:17:28  ... that would not address the case where * has some props and a specific ident has a different set of props
17:17:42  ... first question I had was, as far as specificity, does it apply per peroptery within a highlight?
17:17:50  ... or does it apply to entire pseudo?
17:17:55  TabAtkins: rule is what has specificity
17:18:03  ... props that rule applies cascade using rule's specificity
17:18:18  ... multiple rules applyikng the same thing, look at selector, that determins which shared props win
17:18:30  +1 for `::highlight()` or even `::highlight`. I think ideally all functional pseudos should have parameter-less versions. I would be surprised to see that styling `::spelling-error` though, I'd expect that styles all custom highlights and nothing more
17:18:32  schenney: I believe that means we could apply bramus's specificity suggestion
17:18:44  ... then at style resolution time it would fall through
17:18:50  ... (not what I said in my final comment)
17:18:52  TabAtkins: right
17:19:17  ... it should be exactly the same as if ::spelling-error { color: red } add div::spelling-error {color:blue}
17:19:19  q+
17:19:29  schenney: OK. bramus's suggestion will address
17:19:31  ack dbaron
17:19:39  This should just match VT functional pseudos for specificity
17:19:41  dbaron: was also going to say that the cascade is the normal way to resolve this
17:19:45  ... still 2 choices to do it
17:20:00  ... you do have the choice of whether to say the ident inside of highlight contributes to specificity where * doesn't
17:20:10  ... could define that in different ways but might be constrained by compat
17:20:20  ... sounds like that might have been bramus's proposal
17:20:35  schenney: thats fundamentally what bramus was getting at
17:20:49  ... to paraphrase: highlight with ident has higher specificity than highlight with *
17:20:57  dbaron: that's probably one option, modulo compat constraints
17:21:16  ... we could say for example taht the ident inside highlight is equivalent to class or tagname specificity
17:21:40  ... assuming they have same other stuff in selector, ident would win over *
17:21:49  ... the other option is don't try to differentiate based on specificity
17:21:56  ... devs could still make one override another by order
17:21:59  ... or something else in selector
17:22:05  ack kizu
17:22:16  kizu: did we consider making a general version not just a functional highlgyt>
17:22:27  ... were also considering functional version specifies something more specific
17:22:35  ... what if we just drop () and it's just highlight?
17:22:39  q+ about specificity
17:22:44  sighhhhhh
17:22:45  ack about
17:22:50  ack specificity
17:22:53  schenney: that's a question of syntax we use, we could use that to define custom highlight rules
17:22:55  +1 (in fact, I proposed this above). I think the implied semantics are slightly different though, so need to ask a Q about that
17:22:56  q+ to talk about specificity
17:23:09  ... bramus thought the * syntax was good because it aligns with similar types of functions
17:23:18  ... in view transitions and scroll marker groups
17:23:23  ... would be consistent
17:23:25  ack lea
17:23:43  lea: question: is this pseudo element intended to style every highlight?
17:23:54  ... or including spelling error or just custom highlights?
17:24:02  schenney: just custom highlight swhich have this problem due to idents
17:24:09  lea: agree with kizu that having a version without () makes sense
17:24:24  q+
17:24:27  ... it's a pattern we've supported before where we allow no parens in functional pseudoes
17:24:40  ... bare highlight pseudo might imply to some that it also affects spelling error
17:24:46  ... whereas parens makes it more clear
17:25:02  ... as a general design principle, if we have () also good to have a version without
17:25:03  ack TabAtkins
17:25:03  TabAtkins, you wanted to talk about specificity
17:25:16  TabAtkins: re: specificity I don't think there's any back compat issues
17:25:21  ... given that highlights are terminal
17:25:32  ... we could set whatever specificity we want
17:25:40  ... and it wouldn't affect any existing highlight pseudo
17:25:46  ... some amount before pseudo, some for pseudo, that's it
17:26:03  ... we could still say highlight with a tag is element equivalent, with a * is * equivalent
17:26:03  ack ntim
17:26:09  +1 to tab, I was confusing myself earlier :-)
17:26:13  ntim: I think we should aim for consistency with view transitions pseudos
17:26:17  ... especially functional once
17:26:23  s/once/ones/
17:26:29  ... where you have to specify either * or ident
17:26:42  ... for specificity it should also be consistent with v-t
17:26:55  schenney: I couldn't find anything about v-t * specificity or how it would work
17:27:03  ... where * and ident could apply to same
17:27:10  TabAtkins: in v-t 1 section ??
17:27:15  ... talks about pseudos in general
17:27:15  https://drafts.csswg.org/css-view-transitions-1/#named-view-transition-pseudo
17:27:18  s/??/3.2.1/
17:27:25  schenney: did it talk about *?
17:27:30  or https://www.w3.org/TR/css-view-transitions-1/#named-view-transition-pseudo
17:27:30  TabAtkins: [quotes spec]
17:27:49  ntim: what I said also implies that I don't think we should add a version without parens
17:27:51  ... unless we have one for v-t
17:28:06  astearns: I think we're converging on allowing * for highlight pseudo
17:28:14  ... that applies no specificty, on v-t model
17:28:17  ... objections?
17:28:28  RESOLVED: Add * to highlight pseudo
17:28:39  astearns: whether we have a version without parens can be a separate issue
17:29:00  bramus: should we also resolve that specificity is 0?
17:29:11  RESOLVED: Specificity of * in highlight pseudo is 0
17:29:39  astearns: we are following the v-t model
17:29:59  github-bot, take up https://github.com/w3c/csswg-drafts/issues/10972
17:29:59  Topic: [css-cascade-6] Add a `media()` function for `@import`
17:29:59  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10972.
17:30:39  TabAtkins: the @import grammar is a mess because we have to assume whatever follows is a MQ
17:30:48  ... we have some workarounds to put a support after it
17:30:51  ... it's a little weird
17:31:05  .. question here is if we could add a media function like supports function
17:31:15  ... and then change grammar of @import such that it first checks for a boolean expression
17:31:21  ... and if not parse it as an MQ per legacy behavior
17:31:23  ydaniv has joined #css
17:31:36  ... that will allow authors to get full good boolean behavior, even with MQs
17:31:44  ... without breaking naked MQs following import
17:32:16  +1, sounds reasonable
17:32:23  astearns: trying to load this into my mind
17:32:41  ... if what we get is not a boolean, are you sure it's always going to be good to parse it as a MQ function?
17:32:47  TabAtkins: that's what we do today
17:32:52  ... grammar for @Import will try to parse as a MQ
17:32:55  ... which is a broad syntax
17:33:03  ... will eat a lot of things and turn them into unknown MQs
17:33:16  astearns: wondering whether... we're doing this for media function, any others we might want to add in the future?
17:33:29  TabAtkins: problem right now is that imports take bare MQ right now
17:33:36  ... we also have a proposal for supports function
17:33:48  ... this is makeing it so we can do either a bare MQ or dual function with supports
17:33:52  astearns: OK
17:33:59  ... any other questions?
17:34:04  Yeah, @import ... supports() is a thing already
17:34:06  +1
17:34:07  q+
17:34:08  +1
17:34:20  TabAtkins: proposed: add a media function alongside supports function to @import
17:34:35  ... and switch grammar around so that we first try to match as boolean expression with these functions
17:34:37  q+
17:34:42  ack bkardell
17:34:45  ... and if not, treat as bare MQ
17:34:56  bkardell: any preprocessor that tries to enable this?
17:35:02  TabAtkins: I don't think there's one currently
17:35:20  ... just that especially when media type is involved in query, parsing is wider than you think and confusing in some corner cases
17:35:28  bkardell: are there bugs where people are running into this?
17:35:32  TabAtkins: don't know
17:35:39  +1, seems reasonable to me too
17:35:41  bkardell: curious how this came up? is there demand?
17:35:57  miriam: roman brought it up and works on a preprocessor
17:36:08  ack miriam
17:36:14  miriam: this has no impact on order of things, right?
17:36:20  ... layer and scope have to come first, then conditions?
17:36:27  TabAtkins: yes because those are not part of boolean syntax
17:36:47  ack fantasai
17:36:47  fantasai, you wanted to ask for the proposed grammar
17:36:54  fantasai: tab can you type in proposed grammar?
17:37:07  TabAtkins: replace MQ list term with a boolean of the tests we use in if
17:37:11  @import [  |  ]
17:37:11          [ layer | layer() ]?
17:37:11          [ supports( [  |  ] ) ]?
17:37:11          ? ;
17:37:23  TabAtkins: MQ list would become a boolean
17:37:44  dbaron: was part of the intent to allow and and or between media?
17:37:48  @import  layer?  | ] >?
17:37:52  oh - layers right...
17:38:06  TabAtkins: MQless version as an alternative if first presents parsing error
17:38:12  yeah seems reasonable
17:38:17  fantasai: OK I think I understand
17:38:25  I think s/MQless/MQ/
17:38:30  ...basically like added conditional syntax
17:38:39  s/added/@if/
17:38:49  TabAtkins: right now you can't do supports or MQ
17:38:58  TabAtkins: you have to do both
17:39:22  astearns: Proposed resolution is to add media function to the @import syntax
17:39:34  dbaron: I think there's maybe one grammar alternative
17:39:40  ... maybe a boolean in a different way
17:39:51  ... could turn current supports function into boolean supports media
17:39:57  .. and leave backcompat media term after it
17:40:04  ... would in theory allow both
17:40:10  ... might be simpler form parsing perspective
17:40:23  TabAtkins: think that might be better because media function doesnt allow media type, just feature
17:40:31  ... e.g. print, not expressible as a feature
17:40:31  dbaron: ... not sure if it's better or worse.
17:40:37  ... could still put it at the end
17:41:07  TabAtkins: Proposed: expand supports term to be a boolean tree that also supports media function
17:41:23  fantasai: new grammar that was not posted?
17:41:39  TabAtkins: exactly as current except replace supports by supports or media
17:41:47  fantasai: supports(foo) or media(bar)
17:41:51  ... and print
17:42:00  ... is print then intersected with supports?
17:42:05  s/and//
17:42:06  TabAtkins: yes both must be true
17:42:12  q+
17:42:15  astearns: same condition in both, it may or may not match?
17:42:23  ... conflicting things won't match
17:42:27  TabAtkins: example?
17:42:34  astearns: media function can only express features
17:42:42  ... there's a subset of old production which can be expressed infunction
17:42:52  ... you can now have import statements that have media feature conditions in both places
17:42:56  TabAtkins: theoretically
17:42:59  @import "style" supports(foo) or media(bar) print; /* intersects { supports(foo) or media(bar) } and { print } */
17:43:02  astearns: we need to know how to process
17:43:09  TabAtkins: MQ list at end would be AND-ed with other conditions
17:43:29  Proposed: expand supports term to be a boolean tree that also supports media function
17:43:35  fantasai: [points to example above]
17:43:44  astearns: objections?
17:43:50  ack emilio
17:43:59  emilio: not sure about mixing support and media
17:44:09  ... as in allowing you to write arbitrary bool expressions with them
17:44:19  ... because supports has different failure semantics than media
17:44:30  ... when supports doesn't match, doesn't applyu at all
17:44:36  ... whereas media can dynamically match
17:44:41  ... a bit weird when you start to mix them
17:44:49  .. could define that it doesn't do anything if supports condition doesn't match
17:44:56  ... but it's weird since you can also negate them
17:44:58  fantasai: good point
17:45:07  ... maybe media stuff in boolean means that it doesn't download
17:45:11  emilio: but that's bad
17:45:21  dbaron: you could use tristate boolean logic to solve this
17:45:30  emilio: MQ s are also a tristate
17:45:47  TabAtkins: can you elaborate why it's bad if a media function in supports term starts blocking downloading when false?
17:46:10  emilio: because then it goes past 6pm and your computer goes to sleep, download doesn't happen (?)
17:46:20  dbaron: condition changed but you're offline now and can't download
17:46:30  TabAtkins: I don't think we designed this behavior originally to support offline pages
17:46:42  ... we wanted to make sure print media could start wuickly without waiting for network
17:46:47  emilio: Not just print, also resizing
17:47:01  ... don't want intermediate state where page goes below threshold and now have to wait for another download
17:47:17  emilio: suddenly you have an FOUC
17:47:25  dbaron: I'm with emilio that we need to solve this correctly
17:47:33  ...l think it's doable but might need to work out in issue
17:47:42  emilio: could prove that a thing will never match but need to write algo for that
17:47:58  dbaron: the "should we download" algo is "every media function evaluates to unknown"
17:48:09  dbaron: if your top level result is unknown or ture, download
17:48:15  dbaron: but unknown and false is false
17:48:17  TabAtkins: yup
17:48:37  emilio: that works but it's a bit confusing with unknown MQ where that wouldn't ever match
17:48:41  dbaron: two different unknowns
17:48:51  ... known unknowns and unknown unknowns
17:48:56  emilio: that may need to get worked ouyt
17:49:06  ... not blocking on goal of this but speccing and implementing will be more fun
17:49:17  s/known unknowns and unknown unknowns/just don't call them known unknows and unknown unknowns :-)/
17:49:25  astearns: are we taking previous resolution and then working out download sematics?
17:49:29  (important substitution because that was a joke about the Rumsfeld quote)
17:49:35  TabAtkins: I'm fine with that
17:49:49  (i would like to avoid a 4-state boolean logic...)
17:49:54  astearns: Proposed: Expand supports term of @import production to a boolean tree that supports a media function
17:50:00  ... and figure out download stuff as we go
17:50:02  ... objections?
17:50:20  RESOLVED: Expand supports term of @import production to a boolean tree that supports a media function, and figure out download stuff as we go
17:50:21  (I think the two different unknowns *might* be at different stages of the processing pipeline...)
17:50:46  (i dont' think so, based on what emilio was saying about distinguishing between MQs we dont' know the value of, and MQs we dont' recognize)
17:50:54  github-bot, take up https://github.com/w3c/csswg-drafts/issues/6466
17:50:54  Topic: [css-cascade] Evaluate cascade order of ::slotted and global styles in the same conditions
17:50:54  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6466.
17:51:59  [presentation logistics chatter]
17:52:27  lea: looks like this is about well known problem in web components space of slotted having low specificity
17:52:38  ... anything from outside overwrites anything from shadow dom when they target same element
17:52:38  .
17:52:44  ... run in to same problem with host
17:52:51  ... less a problem with part since you need to be very specific
17:52:58  ... but these problems keep coming up with slotted and host
17:53:08  ... even a css reset on outside will override styles on host
17:53:40  ... this is proposing that shadow dom styles fight with global styles at same specificity
17:53:59  ... basically they expect that shadow dom styles have specificity to resolve conflights with light dom styles
17:54:03  ... which I think would make sense
17:54:07  ... but would not be web compatible
17:54:11  ... but problem needs solving
17:54:19  ... it means component cannot rely on styling itself
17:54:29  ... can't use !important since it's a separate origin
17:54:40  ... if you don't use !important, anything from shadow dom has more important
17:54:47  ... if you use !important everything has higher priority
17:54:50  ... none of these are ideal
17:54:56  ... you want component users to be able to style components
17:55:04  ... but also need to be able to provide defaults
17:55:23  ... this is something we keep running into
17:55:30  ... adthis point, I don't think it's web compatible to change
17:55:36  ... which brings us again to having slotted as a combinator
17:55:46  ... there's no way to override this, no escape hatch
17:55:50  ... no special layer people can use
17:56:20  astearns: do you have a solution to summarize?
17:56:29  lea: solution I proposed before was to make slotted a combinator
17:56:34  ... would also solve a bunch of other problems
17:56:35  q+
17:56:41  ... another issue about this
17:56:56  ack dbaron
17:56:59  ... that by itself doesn't solve, but it solves other problems and doesn't have web compat problem so it can have different specificity
17:57:18  dbaron: part of my intuition here is that one weird thing here is that if you want to intermix things that come from inside and outside component
17:57:26  ... and you need to somehow make up how those appear in order
17:57:33  ... because cascade at some level relies on order
17:57:45  ... and if we get rid of distinction between inside vs outside we need to define order
17:57:48  ydaniv has joined #css
17:57:52  q?
17:57:57  ... one weird thing is that order isn't obvious from how stylesheets get linked to different pieces
17:58:00  q+
17:58:05  ... not obvious that this declaration came i the order before or after that one
17:58:11  jensimmons has joined #css
17:58:32  ... this observation, off the cuff, makes me wonder if it would help to have a syntax or component to inject a set of rules into containing page at specific place in the order
17:58:38  ... almost certainly very beginning or very end of order
17:58:46  ... though presumably then those rules would only apply to component itself
17:58:57  ... thus you wouldn't need to worr about collisions
17:59:07  ... not entirely sure that makes sense, but not sure slotted combinator will solve
17:59:14  qq+
17:59:17  emeyer has left #css
17:59:18  ... even with that, we need sensible proposal for order for cascade to work together
17:59:20  ack lea
17:59:22  lea, you wanted to react to dbaron
17:59:34  lea: as I mentioned, slotted doesn't solve the problem, just gives us an avenue to work around web compat
17:59:54  s/slotted doesn't solve the problem/a slotted combinator doesn't solve the problem/
17:59:58  dbaron: I recognize that, just saying that even if we use that as a hook, we still need not just a defined order but a sensibly defined order
17:59:58  q+
18:00:04  ack emilio
18:00:12  emilio: was going to comment on same line
18:00:19  ... don't think slotted combinator helps
18:00:32  ... first it can be mixed with other selectors, might care about host and whatnot
18:00:50  ... also becomes subtle to handle because you want to get all the rules that go in a particular spot together
18:00:55  ... poking at selector is not a great way to do that
18:01:09  ... potential alternative that could work and give some flexibility is some sort of wrapping at-rule
18:01:17  ... we need to define requirements of this properly
18:01:34  ... because you may want to inject at beginning or among other rules, or something else
18:01:43  ... I don't think we thought about specificity of slotted [??]
18:01:54  ... with intent of them competing for other spots
18:02:15  ... my point is, I think some way of grouping rules that you want to sort outside is probably an easier avenue to explore
18:02:30  ... easier to understand, this weird selector does same thing as this old selector but in subtly different way
18:02:41  ... also allows tweaking, inject beginning, inject at end, somewhere else
18:02:49  ... question is how this interacts with current cascade sorting parameters
18:02:59  ... might want to behave as source order, always after other scope, or before
18:03:03  q+
18:03:11  .... assuming the thing people want is to make specificity work as if shadow dom wasn't involved
18:03:15  ack lea
18:03:28  lea: speaking of requirements, one is that the surrounding page should not have to do anything weird for things to just work
18:03:39  ... some ideas floated at points were, special layer name, important layer, stuff like that
18:03:45  ... for component it's ok to do weird things
18:03:56  ... surrounding page should noy have to do anything for tyhings to just work
18:04:02  .. want to drop component into page and have it just work
18:04:14  ... also one thing to keep in mind defining layer is that it's not just one layer
18:04:21  ... nested shadow roots, components containing componentys
18:04:31  ... something can be in shadow dom but function as light dom for components it includes
18:04:39  ... whatevber we define needs to work in that context
18:04:48  ... don't think it matters what order we define, maybe everything after page css
18:05:01  ... or same kind of order as if you were using style or linke element where style appears
18:05:01  .
18:05:08  ... any order is better than no order
18:05:20  ... though I feel weird when bikeshedding the details
18:05:26  ... core problem is how we're going to change this
18:05:34  ... what would syntax look like without combinator
18:05:39  ... can't change how ?? behaves
18:05:41  q+
18:06:10  s/??/::slotted/
18:06:20  ... and I hope we don't introduce some weird word or parameter after it
18:06:34  ... we have another issue for this meeding for allowing complex selectors in slotted
18:06:42  ... this could turn in to a combinator piece by piece
18:06:45  ack miriam
18:07:01  s/this could turn in to a combinator piece by piece/so we're basically turning it into a combinator piece by piece, without the benefits that come with that/
18:07:02  miriam: to build on what emilio was saying
18:07:16  ... if we had any order either the component styles are firsty or they're lad
18:07:24  ..they'd compete not only in specificity but in layers
18:07:33  +1 to what miriam is saying, great point
18:07:38  ... [missed] that might be right
18:07:54  .... maybe there's an at-rule that relies on what component is doing, what page is doing
18:08:01  ... like emilio. curious about defining problem better
18:08:08  ack emilio
18:08:18  emilio: wanted to emphasize defining what we need
18:08:26  ... constrains solution space
18:08:40  ... if we only care about competing with unlayered styles outside scope, a simple at-rule or some other opt in might do
18:08:50  ... if we need to make layers cross trees somehow, that's a whole different problem
18:09:05  ... I think we need to ... some sort of grouping at-rules feels like most flexible solution
18:09:17  ... also don't want to fixate on a solution without knowing everything we need to solve
18:09:19  q?
18:09:39  astearns: I think I'm hearing that people would like to define the problem we're trying to solve
18:09:57  ... not sure, is the basic problem how shadow dom styles can participate in ordering to work with light dom styles?
18:10:12  ... is it an ordering issue, finding a way of defining how some shadow dom styles can be ordered with outer page styles?
18:10:23  lea: problem is not order; it behaves likle different origin entirely
18:10:32  miriam: letting them interact as though in same context
18:10:46  btw the issue I mentioned: https://github.com/w3c/csswg-drafts/issues/7922
18:10:50  astearns: should we take back to issue with resolution that we want to figure out how to let these separate sets of styles interact?
18:10:59  ...before working on syntax solution?
18:11:19  ... trying to suggest something we can do for this issue, would it be better to leave this one be for now?
18:11:31  lea: wonder if there's web compat research we can do?
18:11:38  ... definitely won't be compatible
18:11:59  emilio: 90% sure that if I make a change and try to start Firefox, it won't look like Firefox
18:12:12  astearns: suggestions for how we should proceed?
18:12:26  emilio: think it might be useful to have a more focused issue on defining exactly what we need
18:12:36  ... this discussion has gone on in that issue for a while
18:12:44  ... not sure that would be in practice vs continuing in this issue
18:12:50  miriam: there are several related issues here
18:13:02  ... maybe there's a meta issue that needs to nail down the problem instead of individual issues
18:13:08  lea: I think that makes a lot of sense
18:13:18  ... need to look at all issues around targeting shadow dom styles together
18:13:27  ... I could take an action item for meta issue
18:13:37  astearns: let's leave this issue's discussion there
18:14:02  ACTION: lea to create a meta issue on shadow DOM styling and what needs to be solved
18:14:18  lea: to discuss in next telcon or f2f?
18:14:27  astearns: don't know that a deadline is nececessary
18:14:36  ... when we come to sort of consensus in that issue, it will be in next agenda
18:14:54  ... we could set a deadline but I've never seen them work in CSSWG
18:15:13  github-bot, take up https://github.com/w3c/csswg-drafts/issues/8376
18:15:13  Topic: [css-contain-4] Define a range syntax for style container queries
18:15:13  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8376.
18:15:36  miriam: a lot of interest in style queries where we're looking at value of custom prop on parent
18:15:41  ... a lot of interest in a range syntax there
18:15:51  ... e.g. instead of "is the value of my-custom-lenght exactly 1em"
18:15:58  .. should be able to say "is it more or less than 1em"
18:16:00  ...various use cases
18:16:05  proposal: https://github.com/w3c/csswg-drafts/issues/8376#issuecomment-2751161553
18:16:06  s/my-custom-lenght/my-custom-length
18:16:09  ... anders proposed we should be able tyo solve this
18:16:16  ... my final comment linked to his proposal
18:16:20  s/tyo/to
18:16:22  ... adopt MQ range syntax including sandwich form
18:16:32  ... each part can be an order reference to a custom prop
18:16:40  ... equals syntax would match based on value
18:16:45  ... so 1.0 would equal 1
18:16:54  .. whereas current syntax would match serialization which is how it works already
18:16:59  ... so that would be breaking
18:17:04  ... some more detail in there
18:17:14  ... as I understand proposal, we wouldn' tneed to register custom props with any particular type
18:17:18  q+
18:17:23  ... would parse them as any of the numeric types to see if they match
18:17:26  ... if not return false
18:17:35  ... thoughts?
18:17:36  ack TabAtkins
18:17:41  TabAtkins: support this
18:17:45  ... as described exactly
18:18:06  ... one detail of this: this technically means you could just do pure numeric comparison
18:18:15  ... don't need to mention custom prop at all
18:18:19  ... think that's fine
18:18:30  ... going back to yesterday, with if() doing comparisons
18:18:34  ... we should amend that to match
18:18:41  ... so that condition and if function work the same way
18:19:07  astearns: any other places besides style queries where we need this?
18:19:12  TabAtkins: only other similar place is MQs
18:19:19  ... those are explicit that you need a media feature on one side
18:19:22  astearns: OK
18:19:40  miriam: other nice to have here would be special casing 0 to allow comparison to length
18:19:45  ack dbaron
18:19:52  dbaron: I like the initial proposal
18:19:59  ... haven't looked into in as much detail as others
18:20:00  don't necessarily need a zero special-case. sign() returns -1, 0, 1 i think, right?
18:20:05  ... a little nervous about what TabAtkins just said
18:20:18  ... there's a bunch of restrictions around style queries that don't apply to ? 10px
18:20:27  ... maybe restrictions do apply, was thinking they didn't
18:20:30  ... so never mind
18:20:49  TabAtkins: there's other restrictions on other conditions, but style queries are resolved on element itself, not container, should be fine
18:20:51  q+
18:20:57  ack emilio
18:21:14  emilio: on the 0 and lengths: do we know if we allow unitless lengths in MQs right now?
18:21:18  ... I think we might now
18:21:21  s/now/not/
18:21:29  ...not that there's a big use case
18:21:34  ... would prefer to defer it
18:21:38  We allow: https://codepen.io/kizu/pen/ByaPWQv
18:21:48  ... because when you're parsing the terms you dont know what's going to be on the right hand side
18:21:51  ... need to work backwards
18:21:59  ... 0 > 0 comparing lengths or numbers?
18:22:12  astearns: in the interest of time, I think we should punt on unitless 0 for now
18:22:19  emilio: seems fine esp if we do in MQs
18:22:35  astearns: Proposal is to accept 3 part resolution in Anders's comment
18:22:37  https://github.com/w3c/csswg-drafts/issues/8376#issuecomment-2751161553
18:22:37  https://github.com/w3c/csswg-drafts/issues/8376#issuecomment-2751161553
18:23:11  astearns: questions or comments?
18:23:40  lea: [asking about colon semantics]
18:23:48  astearns: that's describing what syntax has now
18:23:54  lea: does property registered or not matter?
18:23:59  miriam: registering fixes that
18:24:05  miriam: if unregistered, blue != blue
18:24:15  TabAtkins: bit about colon isn't meant to change behavior
18:24:32  (blue is equal to blue, but it's not equal to #0000ff
18:24:34  )
18:24:47  lea: do we want to allow these kinds of bare idents in there?
18:24:54  TabAtkins: we allow bare idents in MQ conditional form
18:24:56  ... so consistency
18:25:11  TabAtkins: "width < 600px"
18:25:14  astearns: objections?
18:25:18  RESOLVED: accept 3 part resolution in https://github.com/w3c/csswg-drafts/issues/8376#issuecomment-2751161553
18:26:04  github-bot, take up https://github.com/w3c/csswg-drafts/issues/11754
18:26:05  Topic: [css-multicol] Do we need column-wrap as well as column-height
18:26:05  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11754.
18:26:20  q+
18:26:21  rachelandrew: at last F2F, we resolved to star tspecifying overflow for multicol
18:26:31  ... with column-height set causing columns to wrap
18:26:50  ... morten's been implementing in Chrome
18:27:02  ... we feel quite strongly that we want to maintain column-wrap property as trigger
18:27:15  ... if we have column-wrap, you can set a column-height but not wrap columns and still have spare space in container
18:27:21  ... also other things we get
18:27:30  s/ star tspecifying/start specifying
18:27:32  ... next issue on agenda lets us use column-height to trigger multicol
18:27:41  ... if you have column-wrap as well, could have one column wrapping in block directoin
18:27:51  ... we think it's worth maintaining column-wrap property as trigger
18:27:59  ... if we don't, we might come back wanting to add these abilities
18:28:00  s/directoin/direction
18:28:08  ... asking for a resolution to make column-wrap remain a trigger
18:28:16  astearns: this is what spec currently has?
18:28:27  rachelandrew: that's what is in the draft but not what we resolved on
18:28:44  ... if you have a column-height and not enough space, suddenly you get wrapping
18:28:48  ack florian
18:28:50  ... that could seem magical if not expected
18:28:56  florian: I don't have an issue with column-wrap
18:29:04  ... do have strong views on what its values and default should be
18:29:08  ... probably room for compromise
18:29:26  ... I think that it is a historical oddity that by default overflow columns are as they are
18:29:41  ... not so much that it's magical that column-height flips into weird mode
18:29:50  ... it's that other mode should not be the weird one
18:30:08  ... for compat reasons, either if you opt into it, or if we're in case that already exists, legacy behavior should remain
18:30:18  ... but if we have column-wrap, default value should be auto
18:30:27  ... if you don't set column-height, it does the same thing it always has
18:30:47  ... whether you want to opt into other behaviors, we can discuss that
18:31:17  ... I suspect it's possible given example that you set both column height and height of container and that you do want overflow in inline direction
18:31:22  ... but I don't think this will be typical
18:31:32  ... typical thing will be for things to go in block direction of document
18:31:44  ... I think it might also happen that you set the height of your container and don't set height of columns
18:31:49  ... so if you have too many they will be overflowing
18:31:59  ... but you'd rather have overflow in block direction than inline direction
18:32:04  rachelandrew: having opt in makes sense
18:32:26  florian: I do think default should be that , where we can, as soon as you constrain oclumn height, they overgflow in block direction
18:32:31  ... taht tells me default value is audo
18:32:43  ... taht was reqason I didn't want to introduce property, I thought default should be auto
18:32:51  rachelandrew: I think that's also where morten is going in his comments
18:32:54  ... that seems reasonable
18:33:03  ack fantasai
18:33:14  fantasai: mostly agree with florian
18:33:38  ... main question I have is, are there any use cases other than wanting shorter column-height that overflows to right, for having htis property exist?
18:33:41  ... doesn't seem like common case
18:33:54  ... reasonably intuitively solved with wrapper element
18:33:57  q+
18:34:01  ... in which case I don't see that the column-wrap propertu is adding much value
18:34:09  s/propertu/property
18:34:10  florian: don't have a strong answer for value of propertyu
18:34:14  ... but for property itself
18:34:15  ack florian
18:34:25  s/propertyu/property
18:34:59  florian: use case of wanting columns to wrap but setting column-height to height of container
18:35:11  fantasai: in that case I suggest addding a keyword to column-height
18:35:18  ... stretch or auto, which sets to height of container
18:35:23  ... then we don't need new property
18:35:39  florian: from a use case point of view, could you wantr columns to overflow in block direction? I think so
18:35:54  isn’t basic paginated epub-style layout the block direction case?
18:35:57  ... rachelandrew's use case: set ehight of container and height of column to something smaller use alignment to play with extra space?
18:36:05  rachelandrew: carousel use case
18:36:14  florian: interesting but lower priority, would rather deal with it later
18:36:21  astearns, depends on the reader, but yeah it's a common case
18:36:24  rachelandrew: starting with auto is reasonable
18:36:41  ... magical-ness of just doing this on height is also could cause unexpected things
18:36:55  florian: not so much magical doing it on height .we should have had it in block direction in the first place
18:36:58  ... so let's do it
18:37:15  ... for legacy reasons, cases that behave otherwise but we're stuck with that
18:37:32  ... should we have keyword in one case wrapper in the other? I don't find it weird
18:37:37  fantasai:[missed]
18:37:48  rachelandrew: we have flex-wrap. it maps to how existing things work
18:38:04  ... if we tie it to behjavior where we have height I think that limits us to things we might want to do in the future
18:38:14  ...having in the future ability to use alignment adds use cases
18:38:28  s/behjavior/behavior
18:38:29  ... things I see people do with multicol using inline direction overflow now, think it might be useful
18:38:39  ... I think it's cleaner to say ? makes it wrap
18:38:54  florian: regardless of single column use case we want alignment propertiers tyo work
18:39:04  ... distribute extra height through alignment properties
18:39:15  ...as long as they do work, having them work with single row of columns...sure
18:39:34  ... if you want column to overflow to right... dont think that's a good design in cases but maybe in carousel case it is
18:39:44  ... tiny part of system, opt in to something we have anyway
18:40:04  fantasai: can see argument for ? applying in multicol but ?? seems mostly useless
18:40:13  s/propertiers tyo/properties to
18:40:20  ... the column-wrap property isn't adding much to css
18:40:32  rachelandrew: helping it behave more like other things in css
18:40:38  ... use alignment properties similar to how they work in flexbox
18:40:46  ... we have enough stuff that behaves kind of weirdly
18:40:53  ... my initial take was to model close to flexbox
18:41:02  ... benefit to keepingthings like alignment mostly the same
18:41:08  ... extra propertyu doesn't seem lie a big dea
18:41:17  fantasai: in flexbox. align-content only works on ? flexboxes
18:41:23  s/?/multiline/
18:41:29  (although i don't think that was a good decision)
18:41:30  florian: my only sketch of set of peoprties opn multicol has thi sone
18:41:47  rachelandrew: think we should do it now and then it's sort of clear what ??
18:42:09  fantasai: I think we're arguing back and forth, should make a blog post with examples of these things and get more opinions
18:42:23  florian: right now ED has property with no auto value
18:42:32  ... would like to introduce auto as initial value
18:42:44  ... does traditional things if you don't specify column-height, does ?? if you do
18:43:08  ... if we decide later can change, would rather ED doesn't stay as it is currently
18:43:17  astearns: 2 people i room think we should have it, 1 who doesn't
18:43:21  ... I'm ok keeping it
18:43:34  fantasai: we can draft auto value into spec and ask do we need this property
18:43:42  ... try to get more feedback on it
18:43:47  ... think we should have it drafted
18:43:57  I agree with the 3-value auto/nowrap/wrap suggestion
18:44:02  astearns: proposed resolution is to leave property in draft, add new default value of auto, and leave this issue open for now
18:44:09  fantasai: put it in a note and ask people to comment
18:44:20  rachelandrew: I'll write a post and ask for comments but don't expect much
18:44:33  astearns: other commments?
18:44:37  astearns: objections?
18:44:39  Once there is an experimental implementation, I will try it right away in all variations
18:44:48  RESOLVED: leave property in draft, add new default value of auto, and leave this issue open for now
18:44:54  topic: 15 minute break
18:44:59  demo and flag details https://codepen.io/rachelandrew/details/gbOZEBY
19:01:22  github-bot, take up https://github.com/w3c/csswg-drafts/issues/11975
19:01:22  Topic: [css-multicol-2] Should `column-wrap:wrap` alone establish a multicol container? What about `column-height`?
19:01:22  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11975.
19:01:34  rachelandrew: second multcol issue
19:01:39  ... falls out of what we were discussion
19:01:58  ... at the moment only thing that establishes a multicol container is non auto value for column widht or count
19:02:10  ... should column-height trigger multicol?
19:02:18  q+
19:02:19  ...likewise for column-wrap on its own
19:02:31  ... leaning to column-height should, column-wrap shouldn't
19:02:36  florian: agree
19:02:42  ... column-height would be nice if it triggered the thing
19:02:42  ack florian
19:02:47  q+
19:02:52  ... could just set column height and nothing else
19:02:55  .. have pagination which is convenient
19:03:03  ... for column-wrap. suspect not but don't feel strongly
19:03:12  ... could also see diff designs for column wrap we haven't discussed
19:03:20  .. right now not inherited, could be inherited
19:03:30  ... in that case it probably should not turn things into multicol
19:03:45  rachelandrew: might be worth me going through possible combinations of what column-wrap might cause if it were to turn it on
19:03:53  .. I think column-height certainly is an obviouse use case
19:04:04  florian: also column-wrap alone doesn't constrain in height or width
19:04:10  ... would get an inline formatting context and that's it
19:04:13  ... not super useful
19:04:15  - `columns: 2; height: 100px` → overflow in inline direction
19:04:15  - `columns: 2; column-height: 100px` → overflow in block direction
19:04:15  - `columns: 2; height: 100px; column-wrap: wrap` → overflow in block direction
19:04:15  - `columns: 2; column-height: 100px; column-wrap: nowrap` -> overflow in inline direction
19:04:15  ack kizu
19:04:24  kizu: posted how I think it could work
19:04:29  ... if we also make column-wrap turn this on
19:04:37  ... we could just have column swith fixed height by default
19:04:44  .. right now columns overflow in inline direction only
19:04:50  .. could make column-wrap do this in regular direction
19:04:57  ... could work the same with columns and without columns
19:05:06  astearns: in all of your examples in IRC there are multiple ??
19:05:11  kizu: could work the same
19:05:12  s/??/triggers/
19:05:20  .. could enable them just overflow in block direction
19:05:45  astearns: first resolution is that column-height other than initial value turns on a multicol container
19:05:49  sgtm
19:05:51  astearns: objections?
19:06:00  RESOLVED: column-height other than initial value turns on a multicol container
19:06:13  astearns: should we leave column-wrap alone for now?
19:06:19  rachelandrew: probably reasonable given we have queries about that
19:06:25  ... will raise separate issue for that
19:06:35  astearns: would have to be if column-wrap is anythong other than auto or no-wrap
19:06:44  s/anythong/anything
19:06:45  ... can leave to another time
19:06:56  florian: suspect we want to not do it but can take extra time to think about it
19:07:23  github-bot, take up https://github.com/w3c/csswg-drafts/issues/9326
19:07:23  Topic: [css-grid-3][masonry] variable track sizes + dense packing has poor performance
19:07:23  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9326.
19:08:15  ethanjv has joined #css
19:08:33  fantasai: one of the challenges brought up with masonry was that we have this dense keyword
19:08:36  ... for grid placement
19:08:40  ... what does that mean in masonry?
19:08:52  present+
19:08:55  ... when you have variable width columns knowing which slots you can place an item into for a perfect result
19:09:09  ... would mean having to size the item into each column width, calculate its height in order to figure out if it fits in that slot
19:09:16  .. that's a lot of work browser probably doesn't want to do
19:09:22  sgill has joined #css
19:09:32  ... we talked abou tit, suggestion is to lay out the item where it would be without dense packing
19:09:34  .. likely to stay there
19:09:57  ... if it's short enough to fit in a gap left by spanning elements, with the same used width, put it in that gap
19:10:00  q+
19:10:06  q+
19:10:12  ... if you have a masonry layout where all tracks are same width, this is perfect algorithm
19:10:31  ... if a masonry layout with 2 track widths, an item that would be placed in a wider track would only move into a gap left in a wider track
19:10:35  .. likewise for narrow tracks
19:10:42  ... in most cases you end up with dense packing you expecty
19:10:57  .,.. but if you have a lot of different widths and not many items, maybe you leave gaps that could have been filled
19:11:07  ... we think this is close enough and addresses most common use cases for dense packing
19:11:13  ack florian
19:11:19  florian: I think that makes sence
19:11:28  ... supect my line of questioning will be shut down but want to check
19:11:54  ... as I was listening and mostly agreeing, was wondering whether, when you check for other columns to move to, check for columns same size or bigger?
19:12:01  ... then you would have to relayout but would know it fits
19:12:08  fantasai: don't know if it fits due to aspect ratio
19:12:12  florian: thanks for confirming
19:12:18  ... with that explored think that makes sense
19:12:23  ack TabAtkins
19:12:26  TabAtkins: also agree with this proposal
19:12:29  q+
19:12:41  ... ethanjv from microsoft has questions
19:12:55  astearns: the way you formulated the issue was talking about tracks with same size
19:13:01  ack astearns
19:13:03  ... but is it about spanners with same size?
19:13:11  fantasai: good clarification, should make sure we get that in spec
19:13:33  astearns: other comments or questions?
19:13:46  https://github.com/w3c/csswg-drafts/issues/9326#issuecomment-2457881349
19:13:55  astearns: Proposed resolution is what is in ^ comment linked above
19:14:12  ... with amendment that it's track spans with same used size are possible targets for moving into more dense packing
19:14:21  TabAtkins: doesn't only apply to single track items, yes
19:14:26  ... 2-track spanner looking at pairs of tracks
19:14:33  astearns: objections?
19:15:06  RESOLVED: Have the proposed algorithm for dense packing, with clarification that it looks at spans with same used size
19:15:29  github-bot, take up https://github.com/w3c/csswg-drafts/issues/10915
19:15:30  Topic: [css-grid-3][masonry] Enabling repeat(auto-fill, auto)
19:15:30  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10915.
19:16:08  fantasai: when we were discussing masonry proposals, one of the points in the display:masonry proposal was that we can have syntax not allowed in grid properties
19:16:12  ...and use that to do cool new stuff
19:16:38  ... one of the cool new things advocated for was repeat(auto-fill, auto)
19:16:57  ... which we don't allow in grid because grid figures out how many tracks exist before figuring out their sizing
19:17:06  ... but in masonry we have to figure out the track sizing before we can do placement
19:17:32  ... so we have this rule where we size the tracks as if every auto placed item was placed in the track
19:17:48  ... and that allows us to resolve the sizes of tracks before doing actual placement
19:18:01  ... by doing that, it means we can resolve track sizes without knowing which items are placed in them
19:18:12  ... so we could in theory do track sizing even before we know how many tracks there are
19:18:22  ... so that would enable repeat(auto-fill, auto)
19:18:24  repeat(auto-fill, auto)
19:18:30  ... which figures out how many tracks you could maybe fit
19:18:49  ... by doing the sizing as if all items were in this auto track, sizing it, then using resulting size to figure out number of repetitions
19:19:09  ... this issue is about, should we try to add something like this to grid track sizing in general
19:19:17  ... and how do we feel about questions around explicit placement
19:19:30  .. and the fact the auto we use to calculate repeats is not the same as auto we might set the track at
19:19:54  jensimmons: one question I'd love to hear from rachelandrew or others on
19:20:02  ... is this really useful to authors?
19:20:14  ... I don't think it is and can explain why but would like to hear from those who think it is useful
19:20:43  TabAtkins: I think that it's useful to have by default a masonry ... so long as your elements are reasonably sized by themselves
19:20:50  ... e.g images with natrual sizes
19:21:04  ... having default behavior to declare a masonry container be: give me as many columns as I need for these children
19:21:12  ... seems like most useful default absenty anything else
19:21:20  ... there are cases where it won't work e.g. if it's all text
19:21:30  ... in a lot of cases you will, e.g. explicitly sized elements
19:21:37  ... you can always adjust from there if needed
19:21:46  ... but it will at least be a decent answer that looks like a masonry right away
19:21:50  fantasai: we have 2 issues
19:21:54  ... separate issues
19:22:04  ... what should initial value be is next issue
19:22:12  ... this issue is whether we should have this capability at all
19:22:13  q+
19:22:18  ack fantasai
19:22:18  fantasai, you wanted to clarify the issue scope
19:22:18  ... which is different from inital value
19:22:26  ... I thnk there are use cases where this would be useful
19:22:36  TabAtkins: I think this is a useful value because it gives an okay initial result
19:22:37  q+ to ask what happens when it won’t work
19:22:51  jensimmons: I do understand what we're talking about, whether it's initial value or not, I question whether it's worth doing
19:23:02  ... if it's easy to do, won't hurt anything, if it's hard. not worth it
19:23:05  ... sounds amazing on its face
19:23:16  ... where you put auto, either intentionally or by defeault
19:23:21  ... and you don't have to worry about defining track sizes
19:23:28  ... or this many tracks between these sizes
19:23:36  ... instead you can automatically get right amount
19:23:48  ... but when I dug into this, it was complicated enough I couldn't figre it out by myself
19:23:55  ... fantasai and I wanted to write about it
19:24:08  ... one of the hardest things I've had to write about, to wrap my head around what auto does
19:24:14  ... truth is it doesn't do much
19:24:16  s/about it/about it, and it took many days/
19:24:22  ... great that you don't have to worry about track definition
19:24:34  ... but most of the time, author is still going to have to go in and size all the content
19:24:41  ... which takes higher skill and takes longer
19:24:42  q+
19:24:44  ... more fragile to do that way
19:24:49  ... does depend on type of content
19:24:52  ack jensimmons
19:25:03  ... doesn't work for a paragraph because it will just unfutrl and take 100%of containing block
19:25:08  ... will work on text that does not wrap
19:25:10  Example: https://webkit.org/wp-content/uploads/image7-megamenu-light.png
19:25:15  ... one of our demos was a mega menu of all menus
19:25:27  ... as long as no phrases wrap it would automatically make columns
19:25:27  q?
19:25:49  s/unfutrl/unfurl/
19:26:06  ... images are normally bigger than the stuff ? end up on thepage
19:26:08  ... made smaller with CSS
19:26:16  ... not common anymore to put natrual size of image on page
19:26:20  ... often it ends up as a 1x image
19:26:25  ... will look really bad on modern screern
19:26:38  fwiw the menu case in the webkit blog doesn't actually work the `max-contrent` in the repeater gets resolved as zero `grid-template-columns: repeat(auto-fill, minmax(max-content, 24ch));`
19:26:42  ... I think it sounds like this amazing tool but when we looked at the code in depth, we realized it's useful 5% of the time
19:26:49  ... 95% of the time author will get a mess
19:26:56  ... and will need to go size all of the content manually
19:27:03  ... so why? better to just define masonry track
19:27:18  astearns: what is the failure mode? when it doesn't work, then what?
19:27:20  ack astearns
19:27:20  astearns, you wanted to ask what happens when it won’t work
19:27:22  TabAtkins: depends what you mean by fail
19:27:23  q+
19:27:32  ... if there are e3lements full of text with no reasonable isze, you get 1 track
19:27:41  astearns: because 1 element takes up all room anyway
19:27:57  jensimmons: a lot of times you end up with 1 column
19:28:05  ... but could also have >1 column but width is not what you want
19:28:12  ... width of column is width of shorter string of text
19:28:28  ... 2 column s wehre e.g. teaser text unfurls to 1 line in 2 columns
19:28:35  ... each width of longest string of text inthat column
19:28:41  ... or columns with images taht arte all different sizes
19:28:52  ... all at 1x now .look pixelated, look blurry
19:28:58  ... each column is width of widest image at 1x in taht column
19:29:05  .. other images in that column could be narrower
19:29:13  ... file is not big enough to take up whole space
19:29:30  ... widest one will make width of column, others will be blurry and look weird
19:29:34  ack miriam
19:29:42  miriam: have some of same concerns as jensimmons
19:29:50  ... I almost never use auto when I'm sizing columns in grid
19:29:55  ... byut often use it when sizing rows
19:30:00  ... we do allow a row based version of masonry?
19:30:01  TabAtkins: yes
19:30:09  miriam: that's the place I coul dpotentially see it being useful
19:30:15  ... in those failure cases how explicit do I have to get to fix it?
19:30:22  ... I have cards with images that are too big with wrapping text
19:30:29  ... how explicit do I need to be, just max-width?
19:30:34  TabAtkins: depends what you're trying to do
19:30:41  ... might set a number of masonry columns as flexes
19:30:46  ... might set repeat widtyh
19:31:08  fantasai: miriam knows how to set up correct tracks, was asking what happens if she uses this feature
19:31:29  miriam: in order to get some reasonable behavior form auto, if I have images that are big and text that wraps in cards
19:31:37  ... how explicit do I ned to be on each card to make this useful?
19:31:40  TabAtkins: should be just max-width
19:31:44  fantasai: no it won't
19:31:50  ... typically when you're trying to craete columns
19:32:00  ... say I want many columns with width based on size of conten
19:32:09  ... except I want to shirnk content so I set max-wdith 200px
19:32:32  ... and I have a container that's 700px
19:32:41  ... then I will say I can fit 3 columns here
19:32:54  ... so I create 3 columns but then the content is never going to grow to fill...
19:33:05  ... if I said 3 column sI would difined 700px by 3
19:33:10  ... the layout I want is 233px columns
19:33:15  .. cards should be 233px each
19:33:17  ... ignoring gaps
19:33:18  (233px is assuming the deffault "stretch" alignment)
19:33:24  ... but I won't get that because max-width is 200px
19:33:34  ... so my cards will not grow to fill that extra 33px
19:33:40  ... won't get the stretychiness you want
19:33:46  I'm not sure I grasp all the details of this issue so feel free to ignore this if not relevant, but being able to delegate the grid definition to grid items (via `min-*`/`max-*`) instead of having to define everything on the grid container is something I have often wished was possible (and a reason folks reach for flexbox even for some grid-like use cases). It sounds like `repeat(auto-fill, auto)` allows exactly that (?)
19:33:54  jensimmons: there's a drawing of this in the webkit article
19:34:08  lea, it does (subject to the constraints of doing so, which elika is outlining)
19:34:35  jensimmons: columns are squishy but images have fixed max size
19:34:39  ... so you end up with gray space
19:34:45  ... [as seen in example]
19:34:57  astearns: how much would miriam need to do?
19:35:10  fantasai: we figured out something extremely hacky which we would not want to recommend
19:35:11  Thanks TabAtkins! I've also often needed `minmax(auto, 1fr)` or `minmax(1fr, auto)` which never seems to work (though I haven't followed those specs so no idea if that's spec or implementation)
19:35:22  ... takes advantage of how percentages resolve and don't in different parts of algorithm
19:35:30  ... weird stuff we could figure out because I know layout algo
19:35:51  jensimmons: got to a place where explicitly writing track size was way easier
19:35:54  q?
19:36:03  fantasai: overall I think what we found is that this auto track repeat idea for cards, images, ...
19:36:06  ... doesn't really work
19:36:20  ... at the point you figure out how to make it work, you should have just set track size directly
19:36:27  ... is useful for this onscreen example
19:36:29  ... navigation menu
19:36:37  ... with narrow or wider columns depending on text size
19:36:51  jensimmons: thi sisn'r right diagram because all column sare same width
19:37:28  fantasai: this is the right diagram
19:37:35  jensimmons: (retracts comment)
19:37:52  jensimmons: all of these columns will be same width as longest phrase of text
19:37:59  ...a longer phrase will make all columns wider
19:38:06  miriam: I can see some cases where this might be useful
19:38:09  ... seems pretty limited
19:38:12  (i do have a followup, but maybe it can wait until later in the queue)
19:38:19  .. curious if there's a smarter auto we can do
19:38:24  ... smarter auto sounds great
19:38:31  +1 to miriam
19:38:35  ... if there's a way to get ... with the images it's not going to work
19:38:45  ... don't see a lot of usefulness to it but that gets to next issue
19:38:51  ack fantasai
19:39:02  q+
19:39:15  fantasai: one of the other things to point out here is that for grid we size columns depending on what is placed in them
19:39:29  ... even for masonry there are rules about explicit placement that impact columns differently
19:39:37  ... we're assuming in this calc that there's no explicitly placed items
19:39:45  ... we have to be conservative ie. big enough to accommodate everything
19:39:58  ... that's a different algo or wider resulting algo than track sizing algo
19:40:10  .... even if we want to do something like this, another possibility is to give it another keyword
19:40:23  astearns: "big enough for everything" value
19:40:41  fantasai: max-content-evenly
19:40:41  can we consider auto to resolve repetitions as if it was sized under min-content?
19:40:45  The article that we were just looking at is here: https://webkit.org/blog/16026/css-masonry-syntax/#:~:text=Extending%20Masonry%20with%20repeat(auto%2Dareas%2C%20auto) (And that link jumps to the right section) if you want to see more details.
19:40:50  ack iank_
19:41:04  iank_: the megamenu demo doesn't actually work as expected
19:41:13  ... when it's resolving auto repeaters it treats max-content as 0
19:41:21  ... so you get column sof e.g 24ch
19:41:27  ... it just so happens that content doesn't exceed 24ch
19:41:37  ... but if a different language did exceed it, you would get overflow
19:41:40  s/column sof /columns of
19:41:41  ... which isn't desirable
19:41:56  ... so you can't carefully construct your grid-template-columns to satisfy that case
19:42:00  ... I think miriam, on your case
19:42:10  ... adding max-wdith on images probably isn't the right thing
19:42:17  ... what you want is max-width on content wrapper
19:42:31  ... there are a lot of masonry demos out there with e.g. 600px content 3 columns
19:42:38  ... disagree it isn't useful for that case
19:42:39  right, justify-content helps with the results
19:42:51  ... would be sad to drop this feature, think a lot of devs would reach for this initially
19:42:58  rows was mirian's point fwiw
19:43:00  ... to TabAtkins' point for rows this is very useful
19:43:06  q?
19:43:14  ack TabAtkins
19:43:21  TabAtkins: the images leaving leftover spae example
19:43:30  ... does show that if you are stretching columns which happens by default
19:43:32  s/spae/space/
19:43:44  ... and still expecting content to fully fill them you may not get ideal result
19:43:53  ... but if you set max-width 200px and expect 200 to be max width
19:43:57  q+
19:43:58  ... and column sare wider than that
19:44:08  ... still fine because you use alignment to move columns around
19:44:26  ... or center in colunms or whatever
19:44:37  ... and if that is not what you want you still want things to be able to grow more than 20ppx
19:44:46  ..just means you want to be using track sizing at that point
19:45:11  ... nothing wrong with that but based on content you have, lea pointed in chat that that is useful and apparently causes people to reach for flex intead of grid
19:45:24  ... even though grid would be better, would be unfortunate for masonry not to address this
19:45:38  ... finally the initial value if we don't have this is "none' tracks
19:45:43  ... which generates 1 implicit track
19:45:47  ... which is almost never what you want
19:45:50  ... degenerate case
19:46:37  ack kizu
19:46:46  kizu: I agree that for row direction it can be useful
19:46:55  ... not as much in column direction
19:47:02  ... could have text things that don't fully grow
19:47:08  ... unstable in column direction, fragile
19:47:16  .... however I was thinking about this for images
19:47:24  ... this is something where we might want something similar to flex-basis
19:47:31  ... some width that defines this that you're allowed to ?>
19:47:46  ... for example if we have 4 inputs right now, they have some magic built in
19:47:58  ... they have some kind of basis width which is not phrased any other way in css
19:48:03  ... maybe this is something that could be more general
19:48:11  ... another intrinsic dimension of an element we could define
19:48:14  ack fantasai
19:48:14  fantasai, you wanted to respond to Tab's example
19:48:16  .. could be used here and some other places
19:48:31  fantasai: re: TabAtkins - while yes you could distribute space with alignment properties
19:48:36  .. very unusual to want to do that
19:48:42  ... typically want to dsitribute into content itself
19:48:49  ... so in terms of is this useful? yes
19:48:54  ... I think there are cases you might want it
19:48:54  How "mega-menu" renders with a large string. https://usercontent.irccloud-cdn.com/file/gJAPFlqG/Screenshot%202025-04-02%20at%2012.48.21%E2%80%AFPM.png
19:48:58  ... should it be initial value? no
19:49:15  ... while you get a masonry layout immediately, the direction you need to tweak things in, it guides you in the wrong idrection
19:49:24  .. encourages you to tweak item sizing but that's not going to get you where you want
19:49:37  ... by using `none` we make it obious that track sizing will get you to where you want to go
19:49:38  Unusual to justify items, but not unusual to justify content (in my experience) which also gets you there
19:49:47  TabAtkins: don't know I agree it guides you to using sizes
19:49:53  ... don't think it guides you either way
19:49:54  +1 to kizu
19:50:01  ... track sizing and item sizing are not used yet
19:50:04  ... either is available to you
19:50:07  you could make the argument that the normal-value for justify-content to be center
19:50:12  ... container sizing might be what you reach for first
19:50:19  ... it can go either way and either is potentially doable
19:50:26  ... but 1 masonry track for default display is never what you want
19:50:31  q?
19:50:32  ... whereas auto may be what you want
19:50:37  ... and dependoing on content often what you want
19:50:41  ack lea
19:50:59  q+
19:51:01  lea: I definitely have stumbled many times on wanting to set layout constraints on grid items
19:51:07  ... also on flex. settin gon flex items
19:51:13  ... don't have to make assumptions about children structure
19:51:21  ... hide contents and set constratins on items to be sized
19:51:25  ..; which often feels more natural
19:51:37  ... don't have an opinoin on whether it should be default though TabAtkins's argument seems convincing
19:51:39  (kizu's point about the need for a flex-basis analog is compelling to me)
19:51:40  ack miriam
19:51:53  miriam: think I'm coming artound to utility of this even if limited
19:51:55  ... as a default
19:52:03  ... but still  interested onpushing on what kizu was saying
19:52:08  ... and what lea was getting aty with grid
19:52:09  q+
19:52:11  ... can we improve auto somewhat?
19:52:16  ... as a basis for items
19:52:26  ... so we have a target to aim for without using a min or max that will be a final constraint
19:52:33  q+
19:52:48  ... fantasai might be right that it's unuitual to use justify-utems to get rid of space
19:52:52  q+
19:53:08  ... but it's common to use justify-content
19:53:21  ack ethanjv
19:53:24  (a 'justify-content:center' to put the extra space on the outside, for isntance)
19:53:28  ethanjv: following on what miriam said
19:53:35  .. worth exploring that auto behavior can be improved
19:53:49  ... cirrently wackiness of items using max width and ? as acombination to expand to columns
19:54:01  .. could be mitigated by using auto behavior to ???
19:54:31  ... in the case the webkit blog post mentioned
19:54:39  ... wackiness because specified max width but want stratch behavior
19:54:46  ... could explore min-width to auto size content
19:54:53  ... explore in dfferent auto behavior
19:55:02  s/min-width/min-content/
19:55:03  s/min-width/min-content/
19:55:12  ack iank_
19:55:24  iank_: posted a screenshot of how safari renders the menu case with a long string
19:55:30  ... you get content that's ? pretty quickly
19:55:35  ... this is particularly bad fro i18n
19:55:41  ... esp if people want to do that type of repeater
19:55:53  ... you could also argue that normal value for justify-content is center
19:55:56  ... if this is the default
19:56:04  ... think that will match a lot of cases where people want this
19:56:10  that's an interesting idea
19:56:10  ack jensimmons
19:56:12  (found a CodePen that demonstrates the inputs magic that I mentioned for reference: https://codepen.io/kizu/pen/dPbQNyW)
19:56:16  (normal -> center in masonry)
19:56:20  jensimmons: would be interesting to find out how hard to implement
19:56:29  ... if not hard, let's do it and see what happens
19:56:34  .. sometimes we're surprised either way
19:56:38  ... if it is hard don't know
19:56:45  ... have not gone in depth thinking things in row direction
19:56:52  ... don't want to confidently state what I think about that
19:57:01  ... would ask that ... strongly held opinoins stated in this call
19:57:10  ... if you really want to understand this, please read the article we wrote
19:57:21  ... sit down with papere & notebook and thinkg through the algo and how it turns out
19:57:33  ... still don't see where things fall in column direction except very few use cases
19:57:45  q+
19:57:45  ... was surprised ,the more we dug in the worse it got
19:57:53  ack fantasai
19:57:59  q+
19:58:14  fantasai: one thing to point out is, the wy we calculate repetition is going to prefer items that may or may not end up in any of these ? tracks
19:58:23  ... have to calculate number of repeats before we do any placement
19:58:28  ... have to place explicitly placed items first
19:58:38  ... if you have a lot of wide items in explicit track not part of repeat
19:58:42  ... and narrow items in repeat
19:58:48  ... algo will still have to size all of those items
19:58:57  .. doesn't know where explicit items go until it resolves repeat number
19:59:03  ... going to create somewhat surprising behavior
19:59:10  .. wondering if we should give that behavior a different keyword
19:59:23  ... to explain where this sizing goes against items regardless of where placed
19:59:31  ... would also resolve point iank_ brought uyp
19:59:36  ... where if you put this in a minmax right now
19:59:49  ... repetition algo takes a fixed value to calculate the repeat and sizing
19:59:57  ... and if you don't have an explicit value that's currently not valid
20:00:07  ... we'd be making it valid, the ? might get weird if we don't have a keyword
20:00:12  ack TabAtkins
20:00:21  TabAtkins: directly off that, wanted to make sure it was clear
20:00:35  ... ignoring initial value question, behgavior of any auto keyword when given ? as track size
20:00:42  ... illegal in grid because we don't know what goes where
20:00:51  ... propose to allow in masonry because we layou items as we create callins
20:00:55  s/callins/columns/
20:01:19  ...need to be more careful since algo is pretend everything is auto placed
20:01:27  ... and we chop spanners up into pieces
20:01:33  ... but this is the behavior for all intrinsic sizes
20:01:37  .. so if you repeat auto fit min content
20:01:44  ... you get same behavior except using min sizes
20:01:56  ... if we decide we don't want to mislead people into thinking this is the sameas explicit auto size tyracks
20:02:03  ... we'd want to do that for all auto size keywords
20:02:11  ... and ban them in general in auto repeat functions
20:02:19  fantasai: want to bring back the example iank_ put earlier
20:02:20  repeat(auto-fill, minmax(auto, 24ch))
20:02:26  ... that's currently valid
20:02:32  ... adnw euse 24ch to resolve number of repeats
20:02:41  .. the auto that's there gets resiolved after placement in normal way
20:02:44  ... based on content in that track
20:02:44  sgill has joined #css
20:02:51  .. keyworkd we're proposing to add here has different behjavior
20:03:06  ... it's weird that taking out the max and putting auto back is going to get you something fundamentally different
20:03:14  ... that's why I suggest different keyword, it will resolve differently
20:03:22  TabAtkins: comfortable with that
20:03:30  .. would like some kind of auto size auto repetition
20:03:34  ... don't have a strong opinion on how
20:03:45  ... if that's giving bad results more comfortable with abandoning
20:03:51  ... want some way to say "just do the thing"
20:04:01  ...partially for initial value but also think it's useful explicitly as well
20:04:04  ack iank_
20:04:16  iank_: re implementability - don't think it's particularly difficult
20:04:21  ...esp with grouping of masonry items
20:04:29  s/if that's giving/if using normal intrinsic sizes is giving/
20:04:30  ... within context of masonry it's not difficult
20:04:41  ... doesn't work in grid for good reasons
20:04:44  +1
20:04:52  ... so it's disjoint there but relatively straightforward in masonry context
20:04:55  ack fantasai
20:05:07  fantasai: another reason why it's better not to make this initial value
20:05:12  ... and push authors to explicit track sizing
20:05:23  ... it's a little more expensive because you have to scan items up front
20:05:27  .. which yuou don't have to do other2wise
20:05:32  q+
20:05:40  .... other thing to say is if we're adding this, it's not going to be part of grid-template-*
20:05:47  ... need to give it a meaning in grid as well as masonry
20:05:55  `repeat(auto-fill, basis)`, with `masonry-basis: <'width'>` as a new property you can optionally set
20:05:58  ... a bunch of weird things that can happen if author over constrains in both axes
20:05:59  s/it's not going/it’s going/
20:06:05  ... if they don't this can give a useful behavior even in grid
20:06:09  Thinking about a `repeat(sqrt(sibling-count()), 1fr)` default
20:06:16  ack iank_
20:06:24  kizu: I mean.........
20:06:27  iank_: I would somewhat disagree that its more expensive
20:06:43  ... often as soon as you have anything which is going to expect a min auto size or auto track or anything like that you need to group items
20:07:04  ... so I don't think it's actually in common case more expensive
20:07:17  ... basically with masonry we assume everything fits in every column
20:07:22  ... as soon as you have one column thats ?
20:07:30  ... you need to group everything into a group
20:07:39  ... antything except fixed width tracks you need this anyway
20:07:44  @kizu I think `1fr` would need to be `minmax(0, 1fr)`
20:08:01  astearns: hearing a range of opinions between this can be useful in some cases to this isn't entirely un-useful
20:08:05  ... maybe the name needs to change?
20:08:17  ... maybe we need an item size basis that works in all of these?
20:08:26  ... things we need to follow up on
20:08:37  ... not sure we're going yo get farther on this today
20:08:48  ... people have homework to go through blog post, work out their own examples
20:08:54  ... counter blog posts would be welcome
20:09:09  ... should we move on to initial value?
20:09:15  fantasai: let's give it a try
20:09:20  astearns: do you have an alternate in mind?>
20:09:25  fantasai: keep current one
20:09:33  astearns: let's close this issue for now
20:09:42  ACTION: TabAtkins to open item size basis issue
20:09:50  ACTION: fantasai to open issue to change name
20:10:37  Topic: [css-grid-3][masonry] Initial value of track listing for masonry grid axis
20:10:50  fantasai: we just talked a bunch about this
20:10:56  ... 2 options we have contemplated for masonry layout
20:11:08  ... a: be consistent with grid and leave as none which yields single track
20:11:15  ... b: do auto sizing auto fill thing that we were just talking about
20:11:25  ... jensimmons and I suggest current initial value
20:11:32  ... which we see use cases for auto fill auto behavior
20:11:40  ... we don't think it would make a good initial value
20:11:56  q+
20:12:06  astearns: for my clarification, initial value of grid-tempalte-columns is none
20:12:23  ... whatever we decide masontry trigger to be, computed value for g-t-c could become this new value?
20:12:36  q+
20:12:37  TabAtkins: there's back compat constraints we need to worry about but nothing we can't do
20:12:38  ack miriam
20:12:51  miriam: currently the default in grid, initial value is none
20:13:02  ... which falls back to grid-auto-columns and areas
20:13:06  ... assuming those aren't set
20:13:12  ...we end up with similar issues
20:13:18  ... where default for g-a-c is auto
20:13:22  ... and we end up 1 column
20:13:25  ... not an ideal default
20:13:32  ...wish again we had some smarter auto in grid
20:13:36  ... probably too late to change that
20:13:44  ... but that makes me base my answer on how good this other option is
20:13:57  astearns: your answer is?
20:14:03  miriam: we've been talking about variants on this alternative
20:14:18  ... I need to know details of it to know if it can be better than what I consider current broken behavior of grid
20:14:20  ack jensimmons
20:14:42  jensimmons: feel storngly that chanigng default for masonry use cases would be a mistake
20:14:57  ... not going to be an incredibly great default that will give people good looking stuff right away
20:15:04  ... will often be chaos already and people need to figure out why
20:15:23  ... also think people get started, write some code, switch to masonry, now code you wrote is doing something and you don't know hwy
20:15:30  ... eg. meaning of g-t-c changed
20:15:43  ... though that might be less strong an argument if default auto is great, it just isn't now
20:16:02  q+
20:16:05  ... while what miriam is true that if you set auto your layout is half done, that'd be great
20:16:13  ... but reality is you have to write more
20:16:16  (or at least not broken in the single column)
20:16:22  yeah definitely agree that Grid was right to not try and guess
20:16:32  as much as it kinda sucks in practice sometimes
20:16:33  ... with masonry it would be very confusing... one thing to say, you don't have a layout because you haven't made one
20:16:44  ... vs why do I have this layout that looks chaotic, now what do I do with it
20:16:50  ... I have to size all my items?
20:17:00  ... not a route people should have to go down
20:17:09  ... I think what fantasai said is true, better to leave people with no layout
20:17:16  I wasn't asking for grid to guess at tracks, I just want an auto that doesn't blow things out
20:17:19  ... rather than make them get rid of bad layout they have to get to layout they want
20:17:28  ... if it's not hard to implement repeat auto I don't have a problem with it
20:17:36  ... meanwhile I don't know about making it the default
20:17:43  ack astearns
20:17:55  astearns: one of the things jensimmons said made me think about ...
20:17:55  s/I don't know about/no on
20:17:59  ... I've set up a 3 column grid
20:18:08  ... and it looks sort of what I want but what I really want is masonry
20:18:16  ... if the auto is the default, does it override my 3 columns?
20:18:17  fantasai: no
20:18:21  astearns: ok then never mind
20:18:55  jensimmons: the only way people would get this auto default is if they enter right formatting context and *do not* create columns or rows, and trigger masonry and then go to tackle columns
20:19:15  ... which some people will do, but I think authors will do what astearns said, start by defning columns, then trigger masonry, then continue
20:19:30  astearns: I think there might be some value in having as little change as possible on that grid to masonry switch
20:19:39  note: that depends on the not-yet-decided "masonry switch". if it's `display:masonry`, then it's trivial to get this situation
20:20:06  .. switch to masonry thing might change, but if you set columns ... being able to switch back and forth without having it do something for you would be more intuitive
20:20:19  (i also continue to push back on the idea that Grid is a meaningful/useful *fallback* for Masonry.)
20:20:31  (it requires a somewaht careful hand to make that work well, actually)
20:20:33  iank_: push back a little on that specific point, the switch between grid and masonryu in my mind is big
20:20:40  ... changing how things pack, size, etc
20:20:48  ... so still a big switch between modes
20:20:53  (so it *can* be used, in an @supports kinda way, but it's not really suitable as a general "automatic" fallback)
20:21:01  ... so this is still a sueful default for a lot of people
20:21:09  ... degenerate case you still get columns
20:21:23  ... we can work on how useful this will be for web developers
20:21:50  fantasai: 2 things we can do here are
20:21:59  ... straw poll or leave it until we close other issue
20:22:17  astearns: c) leave until we decide on other issue and masonry switch
20:22:21  TabAtkins: leave for now is fine
20:22:22  +1
20:23:17  github-bot, take up https://github.com/w3c/csswg-drafts/issues/10884
20:23:17  Topic: [css-grid] Decide on a name for `item-slack`
20:23:17  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10884.
20:23:41  oriol: we have this property item-slack
20:23:57  ... what it does is allow diverging from sorting items into shortest track
20:24:12  .. with tracks filled to a similar amount it allows following source order instead of shortest
20:24:20  .. value of 0 means strictly shortest track
20:24:27  ... value of infinity means strictly source order
20:24:33  ... this is named 'item-slack' in spec
20:24:39  ... but we didn't resolve on that name
20:24:50  ... not fond of "slack" as non-native Engish speaker
20:25:02  ... there were also some other ideas like strictness, or ??
20:25:10  ... they seem to imply a higher value will implyu more strictness
20:25:14  ... where it's the opposite
20:25:18  s/??/sensitivity/
20:25:19  ... other ideas were threshold, adjust, skip
20:25:28  ... I propose 'tolerance'
20:25:33  ... which some people were recommending recently
20:25:34  s/implyu/imply
20:25:37  We can always change the property values to match the name.
20:25:37  Di has joined #css
20:25:40  ... when I proposed this it was with masonry prefix
20:26:02  ... now that it could be item tolerance, could be more confusing of how you're adding tolerance
20:26:13  ... astearns proposed 'item-fit'
20:26:20  ... someone also suggested "cram"
20:26:26  q+
20:26:29  ... but people liked the word tolerance
20:26:38  fantasai: cram doesn't work for all the cases we're talking about
20:26:48  TabAtkins: can't imply squeezing or stretching
20:26:54  ... can be used for either
20:26:58  ack jensimmons
20:27:01  florian: "fuzz"?
20:27:03  jensimmons: let's rename it
20:27:07  ... I like tolerance too
20:27:15  I'm okay with 'tolerance'
20:27:17  ... it is true that it is confusing by itself
20:27:25  ... item-fit-tolerance is good but long
20:27:31  i don't super like any of the shorter words than tolerance
20:27:34  ... would be all for replacing slack with fit-tolerance
20:27:46  TabAtkins: also a fan of tolerance
20:28:05  astearns: everyone ok with adding 'fit'?
20:28:14  fantasai: don't love it but don't have better suggestion
20:28:21  astearns: we're not tolerating the item
20:28:53  TabAtkins: all the item properties are about placing item, so item-tolerance would also be about placing the item
20:29:05  ... think it already suggests roughly what we're aiming at
20:29:12  +1 to tolerance as well
20:30:05  astearns: item-fit-tolerance was my best name
20:30:13  TabAtkins: I'm always looking out for property name lengths
20:30:26  dholbert: item-fit reminds me of object-fit which is unrelated
20:30:31  ... that slight overlap is confusing
20:30:46  dbaron: don't reject names because they don't go with values
20:30:50  ... can always change values to go with names
20:30:56  TabAtkins: here the values are lengths not keywords
20:31:02  fantasai: what if we rename item-flow to flow
20:31:10  ... then it would be flow-tolerance, flow-direction, ...
20:31:26  TabAtkins: doesn't that land us against flow layout module that describes block?
20:31:35  I like flow
20:31:37  fantasai: besides display keyword is awkward
20:31:46  ... otherwise work really well
20:31:58  https://drafts.csswg.org/css-grid-3/#flow-control
20:32:00  TabAtkins: can we look at item properties real quick?
20:32:28  fantasai: replace 'item' prefix with 'flow'
20:32:36  ... then 'item-flow' becomes 'flow'
20:32:42  TabAtkins: means we can't have a shorthand
20:32:47  fantasai: item-flow -> flow is the shorthand
20:33:10  kbabbitt: "flow-pack"?
20:33:23  fantasai: yes
20:33:24  astearns: don't want to resolve on this change right away
20:33:42  astearns: Proposed: rename item-slack to item-tolerance
20:33:45  SUMMARY: Contemplate replacing 'item-' with 'flow-'
20:34:05  bkardell: it's very difficult for people looking in to understand stability of our decisions
20:34:24  ... we should say, as a currently best working answer but probably to be re-bikeshedded later
20:34:30  astearns: that applies to all our resolutions
20:34:41  bkardell: should be more specific here since it's being cited in intents to ship
20:34:42  Hard to hear Brian
20:34:48  TabAtkins: this one is pretty explicitly tentative
20:35:00  bkardell: can we put the word tenative in the resolution?
20:35:13  florian: all our decisions can be revisited, when we know they will be, dont print your book yet
20:35:21  astearns: Proposed: rename item-slack to item-tolerance ... for now.
20:35:27  astearns: objections?
20:35:38  RESOLVED: rename item-slack to item-tolerance ... for now.
20:35:43  The spec uses the word "threshold" - The item-slack property specifies what the threshold is for considering tracks to be “the same height”, causing them to fill in order.
20:36:08  github-bot, take up https://github.com/w3c/csswg-drafts/issues/5675
20:36:08  Topic: [css-grid] Masonry layout in CSS Grid 3 has potential to cause accessibility problems with reading order.
20:36:08  OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/5675.
20:36:33  rachelandrew: this is an issue raised before we started talking about reading-flow
20:36:38  ... in ~2020
20:36:45  ... this is something we intend to solve with reading-flow
20:36:56  ... really the issue is around what the default behavior is for masonry with regard to reading flow
20:37:01  ... bunch of discussion in the issue
20:37:13  ... we discussed in other issues that we probably wnat some default reading-flow behavior in masory
20:37:17  ... what should that be?
20:37:25  ... keyword values probably are tied to how we decide to do masonry
20:37:31  ... whether it's part of grid or not
20:37:41  ... discussion is, do we want that default behavior
20:37:48  ... so that we use reading-flow and follow the visual by default
20:37:52  .. I think that's how this is solved
20:37:58  ... issue itself predates all that discussion
20:38:10  astearns: have questions about what visual order for masonry would be
20:38:14  I wish we could go back and make the visual order work in grid by default
20:38:22  rachelandrew: in my comment, my point was we broke it donw
20:38:27  Looking in the latest comments of the issue, I do think masonry is much more grid-like in this aspect than flex-like
20:38:36  s/donw/down
20:38:51  https://github.com/w3c/csswg-drafts/issues/5675#issuecomment-2565155995
20:39:38  rachelandrew: issue there is whether we think masonry is more like grid or more like flexbox
20:39:44  ... opposite model in reading-flow
20:39:56  TabAtkins: I believe masonry should be thought of more like grid than flexbox
20:40:06  ... flexbox going in reverse direction can be because you're laying out buttons on other side
20:40:11  ... i.e. outward to inward
20:40:15  ... doesn't apply in masonry
20:40:16  .
20:40:22  .. going to read in visual order regardleses of how we flow it
20:40:26  rachelandrew: makes sense
20:40:48  astearns: the idea of using item tolerance as a measure for which row to assume an item is in makes some sense
20:41:01  TabAtkins: we can almost just use the source order except for explicitly placed items
20:41:08  ... have to reinterpret that if we're doing visual flow
20:41:19  ... having to use item-tolerance in the same way as ? is correct way to go
20:41:31  ... if you explicitly place first item in column 4, then auto flow a bunnch of items
20:41:40  ... pure source order will read item in column 4 first then others
20:41:46  ... but that's roughly visual order anyway
20:41:53  ... visual order would want to reinterpret things
20:41:58  ... so item in column 4 is read 4th
20:42:07  ... use item tolerance to tell when something is next or following row
20:42:15  fantasai: if that 4th item is your righ thand sidebar read that first?
20:42:25  ... which makes me wonder if we should have a mode that allows reordering of auto placed items
20:42:31  ... but leaves explicitly placed items where they are
20:42:37  TabAtkins: if you use order property alongside you get that
20:42:42  fantasai: for some of these cases
20:42:52  scribe+
20:43:25  TabAtkins: My proposal is that masonry, whether we do this by grid values or making new masonry values, but use something like grid-modified order
20:43:34  TabAtkins: and one that's visual, which is auto-flow taken into account
20:43:49  TabAtkins: If you have things you've explicitly placed but should be read first, order-modified grid order works
20:44:10  q+
20:44:12  kbabbitt has joined #css
20:44:14  TabAtkins: For auto-placed items, natural masonry flow already gives a reasonable analog to desired reading order
20:44:20  fantasai: It depends on your spanning stuff
20:44:35  TabAtkins: when using explicit placement for layout reasons, e.g. sidebar and main area
20:44:53  TabAtkins: the 'visual' value would read them left to right, using item-tolerance to decide when something is in the next "row" or whateer
20:45:04  ack rachelandrew
20:45:06  fantasai: I can never keep track of reading-flow values
20:45:14  rachelandrew: not convinced that source order value will always be ok
20:45:23  ... examples I've seen have inserted a very large item
20:45:28  .. which is likely to cause weird jumping around
20:45:32  ... even if source order is roughly correct
20:45:37  ... granted this is on experimental masonry
20:45:44  ... maybe in practice this isn't such a problem
20:45:54  ... but reasonably large items could force things into strange layout
20:45:59  ...that's what the OP of this issue had in mind
20:46:11  ... the idea that you could have slightly odd ordering because of a large item
20:46:25  TabAtkins: OP has very first etxample of a masonry not laid out in masonry order
20:46:40  astearns: it's an example of some reordering htat masonry can do
20:46:48  rachelandrew: don't know what order they were using
20:46:58  fantasai: there have been suggestions to be able to have named tracks
20:47:02  ... e.g. every other track has a name
20:47:12  .. use auto placement in combination with a namer
20:47:31  ... we have talked about for grid and masonry where you can say I want to auto place but only in B-style tracks
20:47:35  ... could result in a layout like this
20:47:44  rachelandrew: would be good to account for that kind of thing
20:48:00  ... e.g. I can see how just having large size items could cause jumping about with just source order
20:48:13  TabAtkins: would like to see an example with large item in correct masonry layout to see effects
20:48:23  ... if you're setting things inmaronry to explicit column sthings can get wawy off
20:48:29  ... but that's something you're doing explicitly
20:48:39  ... don't do that. or do with order to compensate
20:48:44  https://www.w3.org/TR/css-grid-3/#order-accessibility
20:48:56  q+
20:48:57  ... in starndard case of masonry with reasonable tolerance and explicit placement which is not smeantically important
20:49:08  ... then order from masonry layout gives you the best you can automatically doi
20:49:23  ... or any other algo will be similarly abitrarily wrong sometimes
20:49:31  astearns: disagree with one point re; source order
20:49:38  ... even if not explicitly placing anything
20:49:46  ... if what you put into masonry has a large amount of variation in size
20:49:53  ... visual order is going to be completely different from source order
20:50:09  TabAtkins: comic book panel style with wacky arrangement of panel sizes, still read in order
20:50:31  astearns: I heard source order for reading order would be a reasonable thing for masonry generally?
20:50:32  TabAtkins: no
20:50:35  ack astearns
20:50:40  ... we have grid rows and grid columns as values right now
20:51:03  ... either we adopt the grid values interpreting grid rows and grid columns as masonry visual
20:51:21  ... or we adopt two new masonry keywords, masonry order and masonry visual, that do the two things
20:51:37  astearns: we can resolve masonry order is much more like grid order?
20:51:47  rachelandrew: yes, do finer details once masonry is fully decided
20:51:54  fantasai: agree with resolution not sure it solves issue
20:52:07  astearns: it doesn't but it gives you things to throw out at least
20:52:23  astearns: Proposed 1: Masonry reading order operates more like grid than flex
20:52:33  RESOLVED Masonry reading order operates more like grid than flex
20:52:37  RESOLVED: Masonry reading order operates more like grid than flex
20:52:48  astearns: could decide on reusing grid values or making new masonry values
20:52:51  ... or could leave it
20:53:04  rachelandrew: once we have a decision on how masonry is turned on, that makes it more clear
20:53:15  ... in terms of names, better to make sure they work well together
20:53:24  topic:
20:53:36  Topic: Summer F2F Planning
20:53:51  TabAtkins: Current plan is week of August 21st (3rd week of August)
20:53:59  TabAtkins: Does anyone have restrictions on which days in that week?
20:54:21  florian: Mild preference for later rather than earlier in the week
20:59:18  Meeting closed.