15:56:27 <RRSAgent> RRSAgent has joined #css
15:56:32 <RRSAgent> logging to https://www.w3.org/2025/12/11-css-irc
15:56:32 <Zakim> RRSAgent, make logs Public
15:56:33 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:59:54 <lea> present+
16:03:45 <masonf> masonf has joined #css
16:04:01 <dbaron> Present+
16:04:04 <emilio> present+
16:04:06 <masonf> present+
16:04:13 <jarhar> jarhar has joined #css
16:04:14 <cwilso> present+
16:04:14 <cwilso> Topic: sizing base appearance listbox: w3c/csswg-drafts#12510
16:04:24 <cwilso> https://github.com/w3c/csswg-drafts/issues/12510
16:04:29 <dbaron> github: https://github.com/w3c/csswg-drafts/issues/12510
16:04:32 <cwilso> Github: https://github.com/w3c/csswg-drafts/issues/12510
16:04:50 <cwilso> scribe+
16:05:49 <cwilso> jarhar: want to size listboxes with the size attribute.  Listed four options:
16:06:13 <cwilso> ...1: height will just be how many options there are, and height set on them.
16:06:39 <cwilso> ...2: calc exporession to estimate height of each options, and use adder to size with UA style for height
16:06:40 <lea> q+
16:07:14 <cwilso> ...3: use max lines from line clamp stuff based on size attribute; think this would size perfectly but have some issues leverage that right not,.
16:07:31 <emilio> q+
16:07:45 <cwilso> ...4) write intrinsic sizing code that tries to do the same thing that mx lines should theoretically do.
16:08:00 <cwilso> fantasia: what's the issue with max lines?
16:08:14 <jarhar> jarhar has joined #css
16:08:14 <jamesn> jamesn has joined #css
16:08:14 <github-bot> github-bot has joined #css
16:08:14 <florian> florian has joined #css
16:08:14 <tusf> tusf has joined #css
16:08:14 <jcraig> jcraig has joined #css
16:08:14 <cmp> cmp has joined #css
16:08:14 <bts> bts has joined #css
16:08:14 <dbaron> dbaron has joined #css
16:08:14 <ondrejkonec> ondrejkonec has joined #css
16:08:14 <keithamus> keithamus has joined #css
16:08:14 <jbroman> jbroman has joined #css
16:08:14 <foolip> foolip has joined #css
16:08:15 <cwilso> jarhar: not clear if you set max lines and then set height, height will still override?
16:08:33 <cwilso> emilio: max onluy likes clamps.
16:09:07 <cwilso> ...max-lines would only affect like clamping hte auto size to the number of lines
16:09:40 <cwilso> jarhar: tried messing around with what's implemented in chromium, Ian said it will be some time before it's actually implemented and shipped.  Seems spec is a bit unclear at this point, too.
16:09:57 <lea> q?
16:10:00 <flackr> flackr has joined #css
16:10:00 <jarhar> jarhar has joined #css
16:10:00 <jamesn> jamesn has joined #css
16:10:00 <github-bot> github-bot has joined #css
16:10:00 <florian> florian has joined #css
16:10:00 <tusf> tusf has joined #css
16:10:00 <jcraig> jcraig has joined #css
16:10:00 <cmp> cmp has joined #css
16:10:00 <bts> bts has joined #css
16:10:00 <dbaron> dbaron has joined #css
16:10:00 <ondrejkonec> ondrejkonec has joined #css
16:10:00 <keithamus> keithamus has joined #css
16:10:00 <jbroman> jbroman has joined #css
16:10:00 <foolip> foolip has joined #css
16:10:08 <astearns> q+
16:10:23 <cwilso> fantasai: we want authors to have a good solution going into the future; how it works in the first year is less important.,  if max-lines is the right soln but not ready yet, we should say that and work toward it,.
16:10:30 <masonf> q+
16:10:40 <cwilso> ...if we need something temporarily, we can do that.
16:10:58 <cwilso> ack lea
16:10:58 <emilio> ack emilio
16:12:02 <cwilso> lea: I think it should be req that authors can set height to override.  One thing we haven't nohad to deal with before is that until now each option was a single line
16:12:32 <cwilso> ... we should make this a conscious choice one way or another.
16:13:18 <cwilso> astearns: we have talked about multiline before, and noted there's no solution in CSS for that at the moment.  I wonder if we should just go with calc for now because it's as good as we have in current CSS, with the idea that we might replace with max lines or something in the future.
16:13:38 <lea> s/until now each option was a single line/until now each option was a single line. With appearance: base, there can be text wrapping, padding, gaps, etc, so sizing to show N options becomes nontrivial, and CSS does not have a mechanism for this/
16:13:45 <astearns> ack astearns
16:13:47 <cwilso> ... i don't think that will cause a future compat issue.
16:13:48 <astearns> ack masonf
16:14:42 <cwilso> mason: on the web it seems common to use this behavior.  in future with appearance base etc. with multi lines, I don't think this will be a very common case.
16:15:33 <cwilso> ... state of max lines sounds like not quite done?  Maybe option 4, intrinsic sizing, doesn't differ from eventual max-lines case, and we could do it as a magic now and then replace with max-lines eventually?
16:15:38 <lea> q?
16:15:48 <cwilso> emilio: doesn't seem like it's quite the same
16:16:12 <lea> q+ to +1 masonf's idea
16:16:31 <cwilso> ... max-lines changes how height auto behaves; not clear it would work that way.
16:16:42 <cwilso> mason: would be interesting to know how they differ
16:16:50 <jarhar> q+ how does height auto work with max-lines? does max-lines prevent you from setting height to something which makes the listbox size to fit its contents?
16:17:18 <cwilso> dbaron: at some level doing a calc thing or doing a magic intrinsic sizing thing, would be future compatible.  but they're also different things.  We should choose which we think is better.
16:19:03 <astearns> My vote is to account for option height (as much as we can). Consistent sizing across selects seems much less useful
16:19:05 <cwilso> ...in future options can be a different size.  core question is do we want size to give a consistent size, or do we want a more exact per-option size but potentially varying between multiple selects that are styled the same.
16:19:13 <cwilso> ack dbaron
16:19:14 <cwilso> ack lea
16:19:14 <Zakim> lea, you wanted to +1 masonf's idea
16:19:28 <emilio> q+
16:19:38 <cwilso> q+ jarhar to ask how does height auto work with max-lines? does max-lines prevent you from setting height to something which makes the listbox size to fit its contents?
16:20:27 <cwilso> lea: it seems in the short term max lines does do what we want?  I'd like to avoid authors having to duplicate their intent
16:21:01 <cwilso> ack emilio
16:21:47 <cwilso> emilio: max lines proposal would include counting block lines.  Right now it doesn't include that behavior, but it would
16:22:01 <cwilso> ... so you wouldn't need to duplicate the padding, etc.
16:22:38 <cwilso> lea: this might be the right primitive then.  But that doesn't mean we can't ship with magic first then change it.
16:22:48 <cwilso> s/change it/define in terms of max lines later
16:23:04 <cwilso> ack jarhar
16:23:04 <Zakim> jarhar, you wanted to ask how does height auto work with max-lines? does max-lines prevent you from setting height to something which makes the listbox size to fit its contents?
16:23:52 <cwilso> jarhar: if 2we don't use max lines then height auto means?
16:24:09 <masonf> q+
16:25:04 <cwilso> ...david's point about calculating a ceiling making sizing consistent across boxes sounds cool.  But with max lines, I'm not sure what that would do.
16:25:26 <fantasai> https://github.com/w3c/csswg-drafts/issues/12962
16:25:27 <cwilso> emilio: max lines applies to boxes, so ...
16:25:38 <lea> s/it seems in the short term max lines does do what we want?  I'd like to avoid authors having to duplicate their intent/max-lines doesn’t seem to do what we need? I’d like to avoid authors duplicating their intent, even if wrapping is uncommon, padding, or complex options with titles and separate smaller hints, icons etc are fairly common. To dbaron,  If you want a consistent size, you can just set it in CSS easily, but there is no easy escape
16:25:38 <lea> hatch if what you want is the other behavior. It’s totally fine to ship magic in the short-term and explain it later once we figure out the right primitives./
16:25:41 <emilio> s/boxes/blocks
16:26:07 <cwilso> fantasai: I filed this issue: what if instead of counting lines we got foreign independent formatting context?
16:26:38 <cwilso> ... s/foreign/for
16:27:10 <cwilso> ack fan
16:27:57 <cwilso> ...right now max lines only applies to lines of text, but as we see here it might be useful to count the number of flex lines or items
16:28:02 <emilio> q+
16:28:26 <cwilso> ...if we expand max lines to do these kinds of things we can very easily have it solve this case.,
16:30:04 <lea> q+
16:30:19 <cwilso> mfreed: echoing Lea: not sure if max-lines continues to be a good name.  But also, in my experience all in-page selects are either fixed size, blank space below or scroll off page, or all the content up to a minimum size.
16:30:21 <cwilso> ack mas
16:30:23 <cwilso> ack em
16:30:40 <lea> So Chrome does allow a fair bit of styling on listboxes and I cannot for the life of me reverse engineer how sizing works. https://codepen.io/leaverou/pen/NPNJqXw
16:30:55 <astearns> q+
16:30:56 <cwilso> emilio: compat-wise, there's no compat blocker because nobody ships max lines properly now.
16:31:16 <cwilso> ... I'd be fine implementing this behavior without exposing max-lines.
16:31:20 <flackr> flackr has joined #css
16:31:20 <jarhar> jarhar has joined #css
16:31:20 <jamesn> jamesn has joined #css
16:31:20 <github-bot> github-bot has joined #css
16:31:20 <florian> florian has joined #css
16:31:20 <tusf> tusf has joined #css
16:31:20 <jcraig> jcraig has joined #css
16:31:20 <cmp> cmp has joined #css
16:31:20 <bts> bts has joined #css
16:31:20 <dbaron> dbaron has joined #css
16:31:20 <ondrejkonec> ondrejkonec has joined #css
16:31:20 <keithamus> keithamus has joined #css
16:31:20 <jbroman> jbroman has joined #css
16:31:20 <foolip> foolip has joined #css
16:31:25 <masonf> q+
16:31:35 <cwilso> ...problem with intrinsic size: how do you turn it off?
16:31:56 <jarhar> q+ calc() makes it the easiest to get the listbox to fit its contents because you can set height:auto to override height:calc()
16:32:06 <cwilso> lea: I experimented and I cannot figure out what Chromium is doing with intrinsic size in this case.
16:32:18 <cwilso> q+ jarhar to say calc() makes it the easiest to get the listbox to fit its contents because you can set height:auto to override height:calc()
16:32:28 <cwilso> ack lea
16:32:55 <cwilso> emilio: I think Gecko just takes the larger of the options
16:33:28 <lea> yes, that's what Blink seems to be doing as well, even if only the 5th option has the padding, it's taken into account. That's ...not ideal.
16:33:31 <cwilso> astearns: I'm slightly against using option with magic we intend to replace with max-lines
16:34:00 <lea> q?
16:34:03 <cwilso> ...I'm worried we'll create a feature that doesn't work for the magic or not ever finish the feature.  We should clearly define for now and migrate later.
16:34:06 <cwilso> ack as
16:34:08 <cwilso> ack ma
16:34:36 <cwilso> masonf: +1.  usage of this control is almost zero today so there's still time.
16:34:46 <lea> q+
16:35:21 <cwilso> ...let's make the easy things forward and not a footgun.  as long as setting height on overall control overrides max lines I'm good
16:35:25 <cwilso> emilio: yes that's true
16:36:37 <cwilso> fantasai: if max lines changes intrinsic height would that change min-content and max-content as well?
16:36:46 <cwilso> emilio: I forget the status
16:36:48 <cwilso> ack next
16:36:49 <Zakim> jarhar, you wanted to say calc() makes it the easiest to get the listbox to fit its contents because you can set height:auto to override height:calc()
16:37:15 <emilio> q+
16:37:18 <cwilso> jarhar: two arguments in favor of calc: easier for authors to override with height:auto.
16:37:53 <cwilso> ...also if you set size=4 but only have one option, max-lines would vary in height until there are four+ options
16:38:16 <fantasai> that last argument is compelling...
16:38:20 <cwilso> emilio: if we go for calc, we are unlikely to move to anything else in the future.
16:39:10 <cwilso> ...not a fan of that.  This is maybe special case enough, but I think it's the wrong decision
16:39:26 <cwilso> anne: how does this work with one option case?
16:39:33 <cwilso> emilio: one option tall
16:40:30 <ntim> ntim has joined #css
16:40:51 <lea> scribe+
16:40:51 <cwilso> ack next
16:40:57 <emilio> ack emilio
16:41:02 <lea> Lea: calc() with what inside?
16:41:28 <masonf> lea the proposal is roughly here: https://github.com/w3c/csswg-drafts/issues/12510#issuecomment-3411329283
16:41:29 <lea> Lea: max-lines a bit of a red herring since it will have to ship as magic first *anyway*, so we may as well pick the best behavior today and explain it later.
16:41:53 <astearns> I am less optimistic that new magic will always be explainable
16:41:56 <jarhar> lea, it is this:  block-size: calc(max(24px, 1lh) * attr(size type(<integer>), 4));
16:41:57 <lea> Lea: WRT compat, it looks like anything we specify will be different than the current behavior anyway. Multi-pass algorithm seems suboptimal, both for perf and because outliers affect the result too much.
16:42:21 <cwilso> ack next
16:42:26 <lea> Lea: there are reasonable things to do w fewer options, e.g. use the mode or avg
16:42:53 <cwilso> fantasai: I think joey's point that if you only have one item max lines would give surprising behavior is compelling.
16:42:55 <jarhar> q?
16:42:59 <jarhar> q+
16:43:38 <masonf> straw poll?
16:44:10 <cwilso> jarhar: I think we're down to either calc or intrinsic sizing.  I'm still leaning calc, but intrinsic sizing is also okay.  We need to choose.
16:45:07 <astearns> s/be explainable/be eventually explainable/
16:46:20 <lea> So the calc() solution fails to take paddings into account, multiline content etc. These are *very* common
16:46:49 <dbaron> the calc() option could easily consider the default padding on options, but agree that it doesn't consider author changes to the padding
16:47:16 <lea> dbaron: given how conservative default paddings are, this seems largely useless
16:47:40 <fantasai> A) Use calc() equal to size times line height.
16:47:49 <fantasai> B) Use max-lines
16:48:02 <fantasai> C) Ignore size attribute, just do content-based size
16:48:41 <fantasai> D) Magic to multiply size by a heuristic representation of the size of an item (and tie this to some new keyword)
16:49:23 <masonf> D) as-yet undefined magic
16:49:34 <cwilso> ack jarhar
16:51:02 <dbaron> I think the 2 kinds of magic between B and D are whether we (B) size based on the actual N options and (D) look at the options to determine a (max/average) height and then multiply by the size attribute
16:51:30 <fantasai> Exactly what dbaron said
16:51:44 <lea> dbaron: These are not the only options though
16:51:55 <lea> Anyhow, D or B
16:52:03 <emilio> Preferred: B, Acceptable: A, C
16:52:04 <jarhar> A
16:52:08 <lea> scribe-
16:52:13 <masonf> A
16:52:17 <astearns> Prefer B for now, would not object to D
16:52:18 <dbaron> A > D > C > B
16:52:37 <dbaron> (A is best, B is worst)
16:52:49 <astearns> oh wait, I got my letters mixed up
16:52:58 <astearns> Prefer A for now, would not object to D
16:53:08 <fantasai> D, A, B, C
16:53:33 <fantasai> s/dbaron:/dbaron,/
16:54:01 <dbaron> (And fantasai pointed out earlier that B has the problem that a size=4 with 1 option sizes as 1, whereas D doesn't have that problem.)
16:54:19 <fantasai> s/fantasai/Joey/
16:54:23 <lea> E.g. using the actual size if you have >= N items, and some heuristic for the additional items if you have fewer is not covered by either B or D
16:54:56 <masonf> A > C > B > D
16:55:05 <lea> Or using the max height from the first N items. Or the average.
16:55:08 <jarhar> A, or else D
16:55:09 <lea> q+
16:55:28 <fantasai> PROPOSED: Go with A for now, investigate D as a future replacement.
16:55:34 <jarhar> +1
16:55:36 <emilio> wfm
16:55:40 <cwilso> +1
16:55:40 <fantasai> +1
16:56:15 <masonf> +1
16:56:30 <astearns> +1
16:56:57 <dbaron> lea: Between B and D there are other options that do more complicated formulas that consider option sizes when we have them but still do something for missing options.
16:57:01 <cwilso> RESOLVED: Go with A for now, investigate D as a future replacement.
16:57:15 <masonf> Great discussion on that.
16:57:48 <cwilso> jarhar: pinged ian and tab on next issue, they should reply soon.
16:58:07 <cwilso> rrsagent, make minutes
16:58:08 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/11-css-minutes.html cwilso
16:58:15 <cwilso> rrsagent, make log public
17:02:46 <masonf> topic:foo
18:36:30 <front-endian-jane> front-endian-jane has joined #css
18:58:31 <Zakim> Zakim has left #css