- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 11 Dec 2025 17:02:49 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `sizing base appearance listbox: w3c/csswg-drafts#12510`, and agreed to the following: * `RESOLVED: Go with A for now, investigate D as a future replacement.` <details><summary>The full IRC log of that discussion</summary> <cwilso> Topic: sizing base appearance listbox: w3c/csswg-drafts#12510<br> <cwilso> https://github.com/w3c/csswg-drafts/issues/12510<br> <dbaron> github: https://github.com/w3c/csswg-drafts/issues/12510<br> <cwilso> Github: https://github.com/w3c/csswg-drafts/issues/12510<br> <cwilso> scribe+<br> <cwilso> jarhar: want to size listboxes with the size attribute. Listed four options:<br> <cwilso> ...1: height will just be how many options there are, and height set on them.<br> <cwilso> ...2: calc exporession to estimate height of each options, and use adder to size with UA style for height<br> <lea> q+<br> <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,.<br> <emilio> q+<br> <cwilso> ...4) write intrinsic sizing code that tries to do the same thing that mx lines should theoretically do.<br> <cwilso> fantasia: what's the issue with max lines?<br> <cwilso> jarhar: not clear if you set max lines and then set height, height will still override?<br> <cwilso> emilio: max onluy likes clamps.<br> <astearns> q+<br> <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,.<br> <masonf> q+<br> <cwilso> ...if we need something temporarily, we can do that.<br> <cwilso> ack lea<br> <emilio> ack emilio<br> <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<br> <cwilso> ... we should make this a conscious choice one way or another.<br> <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.<br> <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/<br> <astearns> ack astearns<br> <cwilso> ... i don't think that will cause a future compat issue.<br> <astearns> ack masonf<br> <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.<br> <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?<br> <lea> q?<br> <cwilso> emilio: doesn't seem like it's quite the same<br> <lea> q+ to +1 masonf's idea<br> <cwilso> ... max-lines changes how height auto behaves; not clear it would work that way.<br> <cwilso> mason: would be interesting to know how they differ<br> <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?<br> <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.<br> <astearns> My vote is to account for option height (as much as we can). Consistent sizing across selects seems much less useful<br> <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.<br> <cwilso> ack dbaron<br> <cwilso> ack lea<br> <Zakim> lea, you wanted to +1 masonf's idea<br> <emilio> q+<br> <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?<br> <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<br> <cwilso> ack emilio<br> <cwilso> emilio: max lines proposal would include counting block lines. Right now it doesn't include that behavior, but it would<br> <cwilso> ... so you wouldn't need to duplicate the padding, etc.<br> <cwilso> lea: this might be the right primitive then. But that doesn't mean we can't ship with magic first then change it.<br> <cwilso> s/change it/define in terms of max lines later<br> <cwilso> ack jarhar<br> <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?<br> <cwilso> jarhar: if 2we don't use max lines then height auto means?<br> <masonf> q+<br> <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.<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/12962<br> <cwilso> emilio: max lines applies to boxes, so ...<br> <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<br> <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./<br> <emilio> s/boxes/blocks<br> <cwilso> fantasai: I filed this issue: what if instead of counting lines we got foreign independent formatting context?<br> <cwilso> ... s/foreign/for<br> <cwilso> ack fan<br> <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<br> <emilio> q+<br> <cwilso> ...if we expand max lines to do these kinds of things we can very easily have it solve this case.,<br> <lea> q+<br> <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.<br> <cwilso> ack mas<br> <cwilso> ack em<br> <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<br> <astearns> q+<br> <cwilso> emilio: compat-wise, there's no compat blocker because nobody ships max lines properly now.<br> <masonf> q+<br> <cwilso> ...problem with intrinsic size: how do you turn it off?<br> <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()<br> <cwilso> lea: I experimented and I cannot figure out what Chromium is doing with intrinsic size in this case.<br> <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()<br> <cwilso> ack lea<br> <cwilso> emilio: I think Gecko just takes the larger of the options<br> <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.<br> <cwilso> astearns: I'm slightly against using option with magic we intend to replace with max-lines<br> <lea> q?<br> <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.<br> <cwilso> ack as<br> <cwilso> ack ma<br> <cwilso> masonf: +1. usage of this control is almost zero today so there's still time.<br> <lea> q+<br> <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<br> <cwilso> emilio: yes that's true<br> <cwilso> fantasai: if max lines changes intrinsic height would that change min-content and max-content as well?<br> <cwilso> emilio: I forget the status<br> <cwilso> ack next<br> <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()<br> <emilio> q+<br> <cwilso> jarhar: two arguments in favor of calc: easier for authors to override with height:auto.<br> <cwilso> ...also if you set size=4 but only have one option, max-lines would vary in height until there are four+ options<br> <fantasai> that last argument is compelling...<br> <cwilso> emilio: if we go for calc, we are unlikely to move to anything else in the future.<br> <cwilso> ...not a fan of that. This is maybe special case enough, but I think it's the wrong decision<br> <cwilso> anne: how does this work with one option case?<br> <cwilso> emilio: one option tall<br> <lea> scribe+<br> <cwilso> ack next<br> <emilio> ack emilio<br> <lea> Lea: calc() with what inside?<br> <masonf> lea the proposal is roughly here: https://github.com/w3c/csswg-drafts/issues/12510#issuecomment-3411329283<br> <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.<br> <astearns> I am less optimistic that new magic will always be explainable<br> <jarhar> lea, it is this: block-size: calc(max(24px, 1lh) * attr(size type(<integer>), 4));<br> <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.<br> <cwilso> ack next<br> <lea> Lea: there are reasonable things to do w fewer options, e.g. use the mode or avg<br> <cwilso> fantasai: I think joey's point that if you only have one item max lines would give surprising behavior is compelling.<br> <jarhar> q?<br> <jarhar> q+<br> <masonf> straw poll?<br> <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.<br> <astearns> s/be explainable/be eventually explainable/<br> <lea> So the calc() solution fails to take paddings into account, multiline content etc. These are *very* common<br> <dbaron> the calc() option could easily consider the default padding on options, but agree that it doesn't consider author changes to the padding<br> <lea> dbaron: given how conservative default paddings are, this seems largely useless<br> <fantasai> A) Use calc() equal to size times line height.<br> <fantasai> B) Use max-lines<br> <fantasai> C) Ignore size attribute, just do content-based size<br> <fantasai> D) Magic to multiply size by a heuristic representation of the size of an item (and tie this to some new keyword)<br> <masonf> D) as-yet undefined magic<br> <cwilso> ack jarhar<br> <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<br> <fantasai> Exactly what dbaron said<br> <lea> dbaron: These are not the only options though<br> <lea> Anyhow, D or B<br> <emilio> Preferred: B, Acceptable: A, C<br> <jarhar> A<br> <lea> scribe-<br> <masonf> A<br> <astearns> Prefer B for now, would not object to D<br> <dbaron> A > D > C > B<br> <dbaron> (A is best, B is worst)<br> <astearns> oh wait, I got my letters mixed up<br> <astearns> Prefer A for now, would not object to D<br> <fantasai> D, A, B, C<br> <fantasai> s/dbaron:/dbaron,/<br> <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.)<br> <fantasai> s/fantasai/Joey/<br> <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<br> <masonf> A > C > B > D<br> <lea> Or using the max height from the first N items. Or the average.<br> <jarhar> A, or else D<br> <lea> q+<br> <fantasai> PROPOSED: Go with A for now, investigate D as a future replacement.<br> <jarhar> +1<br> <emilio> wfm<br> <cwilso> +1<br> <fantasai> +1<br> <masonf> +1<br> <astearns> +1<br> <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.<br> <cwilso> RESOLVED: Go with A for now, investigate D as a future replacement.<br> <masonf> Great discussion on that.<br> <cwilso> jarhar: pinged ian and tab on next issue, they should reply soon.<br> <cwilso> rrsagent, make minutes<br> <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/11-css-minutes.html cwilso<br> <cwilso> rrsagent, make log public<br> <RRSAgent> I have made the request, cwilso<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12510#issuecomment-3642873325 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 11 December 2025 17:02:50 UTC