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