csswg-drafts
csswg-drafts copied to clipboard
w3c
[css-forms-1] UA styles for base appearance listbox select elements
We already decided on UA styles for base appearance drop-down single-select elements here: https://github.com/w3c/csswg-drafts/issues/10857
I'd like to decide on UA styles for listbox select elements, with or without the multiple attribute. Most of the styles from drop-down single-selects can be reused, but here are some changes I'd like to propose. Until https://github.com/w3c/csswg-drafts/issues/7422 gets resolved, I'm going to write these with a :has-picker pseudo-class.
Make these style which currently apply to the select element only apply to drop-down selects:
select:has-picker {
border-radius: 0.5em;
padding-block: 0.25em;
padding-inline: 0.5em;
min-block-size: calc-size(auto, max(size, 24px, 1lh));
min-inline-size: calc-size(auto, max(size, 24px));
display: inline-flex;
gap: 0.5em;
field-sizing: content !important;
box-sizing: border-box;
}
Add these styles which only apply to listbox selects:
select:not(:has-picker) {
display: inline-block;
overflow-inline: auto;
overflow-block: auto;
}
Change the selectors of the hover/active/disabled rules to only apply when the select has a picker:
select:has-picker:enabled:hover {
...
}
select:has-picker:enabled:active {
...
}
select:has-picker:disabled {
...
}
Here is a PR which is probably easier to read than the style rules I put in the OP: https://github.com/w3c/csswg-drafts/pull/12511
Instead of comparing the styles to select with a picker, maybe just listing the styles which will apply when its a listbox is easier to understand:
select:not(:has-picker) {
overflow-inline: auto;
overflow-block: auto;
border: 1px solid currentColor;
display: inline-block;
user-select: none;
}
The CSS Working Group just discussed [css-forms-1] UA styles for base appearance listbox select elements.
The full IRC log of that discussion
<fantasai> lea, if we go down that line we can maybe call it `:embedded-field` or something. I think selecting based on that vs mixing it up with pickers is better.<fantasai> in many form controls the picker is an optional aid, not the core part of the control
<masonf> jarhar: we defined a bunch of UA styles for customizable-select when it has no size attribute and a picker. I'd like to do the same for in-page listbox without a picker, with or without multiple.
<lea> q+
<lea> q-
<masonf> jarhar: I think this is easy, compared to single-select, since it's just removing some things like button styles.
<Lwarlow> Yeah the embedded vs in page with optional picker is interesting
<lea> q+
<masonf> jarhar: I wrote a comment about 5 styles that should apply (commented on the issue).
<masonf> jarhar: overflow, border, display, and user-select
<masonf> jarhar: what do you think?
<astearns> ack lea
<una> q+
<masonf> lea: one requirement - it should be possible to size intrinsically to fit the contents.
<masonf> lea: seems like it should be possible, just don't want to lose track of this
<masonf> lea: once you can style them, you've got flexibility to change the appearance a lot. All of these require no scrolling.
<masonf> lea: cannot describe the way that listbox sizing works currently. Maybe that just goes away with appearance base. But that means that size stopped working.
<masonf> lea: if you say size:3 it doesn't do 3 lh's it says three options
<masonf> lea: however tall three options are. Not sure this is useful, but maybe.
<astearns> ack una
<Lwarlow> Q+
<masonf> una: generally these look good. I'm always a fan of simplicity. Fewer things for authors to override.
<masonf> una: I noticed padding block and inline that was removed. Why remove padding and gaps and things?
<masonf> jarhar: I think the padding and gaps are to space the content inside the button, so the picker icon has space.
<masonf> jarhar: and to make sure text inside the button is spaced away from edges. With listbox, that doesn't apply.
<lea> q+
<masonf> jarhar: option elements will already have those rules, and the options will fill the select.
<masonf> una: makes sense
<astearns> ack Lwarlow
<masonf> lwarlow: one other thing is field sizing as a default still makes sense. The fixed styling if we're allowing it should be opt-in rather than opt-out.
<masonf> lwarlow: by default people will want it to just fill based on the number of options, and set a max height. Rather than being fixed.
<masonf> lwarlow: don't need to opt in to field-sizing: content
<masonf> lwarlow: only reason this isn't used more is that it isn't implemented everywhere
<lea> s/cannot describe the way that listbox sizing works currently. Maybe that just goes away with appearance base. But that means that size stopped working./CSS cannot currently describe the way that listbox sizing works currently. Maybe that's okay and you lose that with appearance base. But that means that the `size` attribute stops working. Or maybe we define `size` to mean "this many `1lch`" and not "this many options"/
<masonf> lwarlow: other than that, these styles make sense
<masonf> lwarlow: don't think it should have border or border radius
<masonf> lwarlow: just matching everything else makes sense. Should be box-sizing:border-box maybe?
<masonf> lwarlow: not having overflow:scroll is good. That's odd currently.
<astearns> ack lea
<masonf> lea: I agree with not having border radius, and generally the fewer styles the better.
<masonf> lea: not sure about padding. Usually listboxes it's not the select that has padding, it's the options. Same for gap, usually no gap.
<masonf> lea: field-sizing: content with !important. Generally do we really need that? In appearance:base it gets sized as a regular element. Not sure what field-sizing would do there?
<masonf> lea: agree that most authors want to set max height. Do we really need field-sizing, and !important?
<masonf> lwarlow: reason for that is that at least in Chromium, if you didn't have it, the computed value would be fixed. Felt strange
<lea> also just realized I was reading the select styles as listbox styles.
<masonf> lwarlow: question about form controls having special behavior in base appearance mode
<masonf> lwarlow: there's a CSS issue discussing this
<masonf> lwarlow: some people might like select's fixed behavior, automatically sizing based on longest option
<masonf> lea: I was reading the select styles, they do make sense for drop downselect, I just meant for listboxes
<lea> q+
<masonf> lwarlow: don't need the !important, that's likely an impl detail
<masonf> lwarlow: you can't do fixed sizing width-wise, and no easy way height-wise. Might be that we can't allow fixed mode.
<masonf> lea: we could also say field-sizing always resolves to content in appearance base or something
<masonf> lea: I was expecting flex, but you have inline-block. Authors can override.
<masonf> lea: do browsers use flex or something else?
<masonf> jarhar: picker with select is a flexbox, I'd imagine it's the same here for listbox right?
<masonf> jarhar: customizable-select picker is display:block
<Lwarlow> Q+
<astearns> ack lea
<astearns> ack Lwarlow
<masonf> lwarlow: we probably need a wider discussion of the display value in appearance:base.
<ntim> q+
<masonf> lwarlow: maybe it doesn't matter much here, but matters more in other controls
<lea> (also fewer things for authors to override)
<masonf> lwarlow: we should be consistent. Maybe select is special.
<astearns> ack ntim
<masonf> ntim: one goal for appearnace:base is to make it as close to a plain div as possible.
<masonf> ntim: field-sizing:content isn't like a plain div. If you put display:block on a div, it fills the available space. That doesn't happen with field-sizing:content
<masonf> ntim: want to solve this generally
<masonf> ntim: maybe new field-sizing:auto value?
<masonf> astearns: want to reduce the number of author overrides, vs having it be close to a div. Those are in tension.
<masonf> astearns: need extra justification for things that make things more complicated for bare div
<masonf> ntim: from perspective of a new author, wondering why form controls behave differently. Try to fix with appearance:base
<masonf> astearns: we have these two sets of styles, but no way (yet) to decide between them
<masonf> jarhar: I took notes, and I'll post back to the issue. On the selector I can just give up on that and just use existing spec concepts to swithc.
<masonf> s/swithc/switch
<masonf> astearns: we can move forward with these rules and have UA magic make them apply
<masonf> annevk: to be clear, I wasn't against exposing it, just wanted it to be consistent
<masonf> annevk: seems like some pseudo class is warranted.
<masonf> astearns: take this back to the issue, debate the things we didn't decide today
comments from meeting:
- no border
- no intrinsic sizing, not sure what the field-sizing value should be to represent this
- box-sizing: border-box
- maybe something else for display value?
In order to incorporate the last comment's suggestions, here are my new proposed styles for list box selects:
select {
overflow-inline: auto;
overflow-block: auto;
field-sizing: content;
display: inline-block;
box-sizing: border-box;
user-select: none;
}
I'm open to suggestions for the display value, I'm not sure if anyone had a specific suggestion.
The CSS Working Group just discussed [css-forms-1] UA styles for base appearance listbox select elements.
The full IRC log of that discussion
<zcorpan> jarhar: I incorporated feedback from the last meeting<zcorpan> jarhar: overflow (etc) examples. Any feedback on these?
<emilio> q+
<zcorpan> fantasai: field-sizing: contents
<astearns> ack fantasai
<zcorpan> jarhar: The idea was ignore the size attribute, make it as tall as it would normally be
<zcorpan> fantasai: OK
<zcorpan> jarhar: Luke I think suggested this. Makes it easer to write tests
<zcorpan> emilio: What is the behavior if you remove field-sizing: contents?
<zcorpan> jarhar: customizable select I didn't use it in the UA style. Turning off intrinsic sizing. We should be consistent, but ok to make changes
<astearns> ack emilio
<zcorpan> emilio: We're making appearance: base select a scrollable block. Get field-sizing: contents for free
<zcorpan> jarhar: We should say field-sizing: content !important
<zcorpan> emilio: Unnecessary? Can remove and have the same effect
<zcorpan> emilio: I think (MISSED) doesn't match other form control behavior
<zcorpan> jarhar: user-select, I can go back to the issue and link the previous discussion
<zcorpan> emilio: makes sense to be consistent, but curious why
<zcorpan> emilio: Could be use cases for e.g. a search field on the picker
<zcorpan> emilio: It inherits down
<jarhar> q?
<jarhar> https://github.com/whatwg/html/issues/8189
Here is the open discussion about field-sizing, which I think we should defer the UA field-sizing value for: https://github.com/w3c/csswg-drafts/issues/11838
Here's the issue about user-select for the select element and buttons: https://github.com/whatwg/html/issues/10876#issuecomment-2555554057
Now that I read the user-select issue again, I realize that it is more about buttons than listboxes or the select's picker, so I think we should remove the user-select rule from my proposed styles here for listboxes and just let it inherit.
Thanks for the feedback @emilio
Here are a new set of UA styles:
select {
overflow-inline: auto;
overflow-block: auto;
display: inline-block;
box-sizing: border-box;
/* Use decision from here for field-sizing when that happens:
* https://github.com/w3c/csswg-drafts/issues/11838 */
}
Okay so coming back to this idk if I was talking nonsense or what I said was scribed incorrectly but lwarlow: don't think it should have border or border radius -> is wrong. It absolutely should have a border style. No border-radius is correct though imo.
Apologies I didn't catch my/the scribe error earlier. But hopefully it's easy enough to undo.
Thanks Luke! Here is the latest set of proposed UA styles with the border put back in:
select {
overflow-inline: auto;
overflow-block: auto;
display: inline-block;
border: 1px solid currentColor;
box-sizing: border-box;
/* Use decision from here for field-sizing when that happens:
* https://github.com/w3c/csswg-drafts/issues/11838 */
}
The CSS Working Group just discussed [css-forms-1] UA styles for base appearance listbox select elements.
The full IRC log of that discussion
<noamr> scribe+<noamr> jarhar:we've discussed this a few times already, I want to do base appearance for base appearance listbox select elements
<noamr> jarhar: I have a proposed UA style
<noamr> jarhar: 5 different rules, see in the issue
<noamr> https://github.com/w3c/csswg-drafts/issues/12510#issuecomment-3254406663
<noamr> fantasai: what is the display type for the popup display?
<noamr> fantasai: for the picker
<noamr> fantasai: it should be consistent between the two
<noamr> jarhar: display:block
<noamr> fantasai: cool
<zcorpan> q+
<fantasai> emilio: Default for overflow-inline is hidden, in Gecko
<cwilso> ack fantasai
<noamr> jarhar: I don't remember the default, I think there was overflow-inline:auto from luke, hidden is not ideal, not sure how prevalent it would be
<noamr> emilio: inline-block would shrinkwrap
<noamr> fantasai: a lot of people would resize this. not unusual for the listbox
<fantasai> Listboxes: https://bugs.webkit.org/query.cgi?format=advanced
<noamr> emilio: should we use the overflow shorthand
<noamr> emilio: unlikely to matter
<noamr> fantasai: in a lot of cases people would expect clipping or ellipsis
<cwilso> ack next
<noamr> zcorpan: the spec doesn't currently say much in the listbox case. is this just for base appearance?
<noamr> jarhar: base appearance
<noamr> emilio: it seems to match non-base appearance axcept for colors\
<noamr> zcorpan: some things cannot be explained by CSS
<noamr> emilio: the thing that can't be explained by CSS are the sizing behavior
<noamr> emilio: the rest is not much different
<noamr> emilio: I think you can't currently create an overflow:visible behavior
<noamr> emilio: do we want the size attribute to work with appearance:base
<noamr> jarhar: based on the previous discussions we want to ignore the size attribute and let it grow vertically
<noamr> fantasai: wouldn't they often want the kind of sizing of the native size attribute?
<noamr> dbaron: it's more complex because there is a math expression with a LH value and a px value for the touch-target.
<noamr> dbaron: we should be careful with overflow values that are incompatible across vertical/horizontal axes
<keithamus> q+
<noamr> dbaron: e.g. overflow-block: auto; overflow-inline: visible, they will affect each other
<cwilso> ack next
<jarhar> zakim, end meeting
Feedback from the meeting:
- should it be overflow:auto instead of overflow-inline:auto and overflow-block:auto?
- some ideas about how to make the size attribute work instead of just making it have unlimited height
Apologies I couldn't be present for this discussion. Using overflow: auto seems fine I think they were separated because initially I had a different value. In the end i think auto is better than hidden for inline.
As for making the size attribute work it might be desirable? Would you then have to set field-sizing: content if you didn't want it at a fixed size? Or would it get a style like below (obviously not exactly) that you can override in CSS?
max-height: attr(size)lh;
min-height: attr(size)lh;
I lean slightly towards ignoring size attr other than for switching and perhaps just including a default minimum height of 3lh or something?
I imagine we'd do something similar for <textarea>?
Yeah I think that I was more hesitant to try doing actual height sizing based on the size attribute because of potential cyclical issues of trying to size the container based on the size of the options, but if we just multiply the size by something more constant then that problem goes away.
We could multiply the sizes bylh or as David suggested to me we could multiply the size by the UA style for options: max(24px, 1lh).
I lean slightly towards ignoring size attr other than for switching and perhaps just including a default minimum height of 3lh or something?
This also sounds very appealing to me. I don't think that we can express the actual size as HTML uses it in CSS, since by default its 4 and the parsing could be different.
I think we have three options:
- Ignore the size attribute and make the listbox indefinitely tall (no height set)
- Ignore the size attribute and make the listbox have a fixed height with an approximation of four options:
calc(max(24px, 1lh) * 4); - Use the size attribute and multiply it by an approximation of option height:
calc(max(24px, 1lh) * attr(size type(<integer>), 4)- The
attr(size type(<integer>), 4)likely doesn't match how the HTML spec calculates the size attribute, so in order to make it match this might have to be done with something special in the implementation rather than just CSS.
- The
Does anyone have opinions? I'm leaning towards options 1 or 2
The CSS Working Group just discussed [css-forms-1] UA styles for base appearance listbox select elements, and agreed to the following:
-
RESOLVED: choose option 3 which uses the size attribute
The full IRC log of that discussion
<masonf> scribenick: masonf<masonf> jarhar: last time, we talked about the height of the listbox. We talked about making it as tall as needed, then we started talking about incorporating the size attribute value.
<masonf> ... dbaron had an idea for using calc to scale with the line height. I also posted a few other options.
<masonf> ... I tried implementing the calc expression and I think it works fairly well. Might not match HTML spec.
<masonf> ...thought about it more, it's likely ok. The place where they mismatch is likely funny edge cases like size=123abc
<masonf> ...you might not get the height you expect, but it's an error anyway, and not common.
<masonf> ...many authors likely explicitly set the size of the box anyway.
<masonf> ...I like the calc expression with the attr(). Any other thoughts?
<lwarlow> q+
<masonf> lwarlow: I'm between option 1 and some form of option 2.
<masonf> ... I think most people like field sizing, and don't want the fixed size in html thing.
<masonf> ... generally that's for textarea but the same thing likely applies to select.
<keithamus> q+
<astearns> ack lwarlow
<masonf> ... maybe we could do a min-height or something? Minimum of 4 but it'll grow. But is that easy for developers to understand?
<masonf> ... one thing about the attr() is that this would be the first place we use it, for base appearance stuff. Makes that a prereq.
<masonf> ... I wouldn't bother with option 3. Likely to not be correct.
<masonf> ... I lean toward option 1, lean to option 2
<astearns> ack keithamus
<astearns> s/lean to option 2/OK with option 2/
<masonf> keithamus: if min/max would have been invented before min-height, we wouldn't have added it. I disagree with using min-height.
<masonf> ... to me this is the right choice. Lists are either very small, or unbounded, and we don't want unbounded to take up the whole page.
<masonf> ... this {not sure which option "this" refers to} is the most reasonable.
<masonf> jarhar: do you like option 3 with attr(size) or option 2 that doesn't.
<masonf> keithamus: I think attr(size) makes a lot of sense.
<masonf> karhar: to luke's point about not being correct - that's definitely true in cases. E.g. when options are >24px tall, the line height doesn't perfectly match the option height.
<masonf> s/karhar/jarhar
<masonf> keithamus: I'd go further - it'd be a nice UX affordance for a user to be able to see all options at once. So I lean toward option 3 because of that.
<masonf> ... you can see the entirety of your selection at once. The choice of 4 seems kind of arbitrary. The average user can rationalize why it can be calculated from the size, but will wonder about the 4.
<masonf> ... same reason why aria-level starts at 2. Why?
<masonf> (because... history)
<masonf> dbaron: there's another option. Have something that depends on the size attribute have a selector that makes sure we're using the size attribute in the first place.
<masonf> lwarlow: but we use that to switch modes.
<masonf> dbaron: ahh the fallback to 4 is just when the size doesn't parse.
<masonf> jarhar: or when you put `multiple` on it
<masonf> dbaron: maybe what I said works then.
<lwarlow> Fwiw the default is approximately 4 options show today
<masonf> zcorpan: current behavior is to show 4 rows.
<masonf> dbaron: the non-base appearance you mean
<masonf> zcorpan: yes
<masonf> zcorpan: seems reasonable to match that
<masonf> astearns: but base appearance is to fix historical things, so we shouldn't blindly copy that.
<masonf> jarhar: we can do infinitely tall then. Makes sense to use 4 if there's no better number.
<masonf> keithamus: what happens if there are options that go beyond one line? Each option takes 2 lines. Do I only see 2 options, not 4 then?
<masonf> jarhar: two lines?
<masonf> keithamus: rich option with two lines. Label and description of label. Each option takes up 2 lines.
<lwarlow> Yes it's true in all desktop browsers that a listbox defaults to "4"
<masonf> keithamus: it's a default, but in this case it's not a useful default.
<masonf> jarhar: if more than 24px tall then you'd just see 2 options.
<masonf> q+
<lwarlow> q+
<masonf> keithamus: are there examples?
<masonf> lwarlow: usage is low
<astearns> masonf: yes, usage is low
<jarhar> masonf: usage is very low
<jarhar> masonf: these are just defaults
<jarhar> masonf: like the old thing, it should just kind of work
<astearns> ack masonf
<jarhar> masonf: if the dev wants the new thing, theyll probably size it
<jarhar> masonf: theyll set a height relative to the page, or calculate it themselves since they know whats in their options
<jarhar> masonf: the default should work in the base case, and if it falls apart when they add a bunch of css, then they should just set the height
<masonf> thanks for minuting jarhar
<astearns> ack lwarlow
<masonf> lwarlow: that brings me back to thinking that whether we use size or not, should the fallback (if it doesn't parse) be just growing to fit content?
<zcorpan> q+
<masonf> lwarlow: might be better behavior. If you want to override, you can.
<astearns> q+
<masonf> ... yes it's just a default, but having a default where it's arbitrary 4 is weird.
<masonf> ... makes sense for a textarea, because you want to see things. Doesn't make much sense here.
<masonf> ... it would grow, if you increase the font size. lh will increase.
<masonf> ... if you're doing formatting such that line height doesn't match the height. E.g. padding.
<keithamus> q+
<masonf> ... does the size attribute for that make sense? Using lh might not make sense.
<masonf> ... I still lean toward growing as the best default. It forces people to think about stuff upfront and size it explicitly, and avoid tripping over it later.
<astearns> ack zcorpan
<masonf> zcorpan: it makes sense to have a default of 4 or some low number. The person writing the CSS isn't the same as the one creating the HTML.
<masonf> ... wordpress themes that are reset stylesheets used on 1000's of sites.
<masonf> ... if you write a stylesheet that uses appearance:base in a default theme. Random webpage uses select multiple with 100 options, it breaks the layout. Wasn't tested for by the stylesheet writer.
<masonf> ... having some consistency with current behavior makes sense. But of course be able to override.
<masonf> astearns: I like option 1 better than the other.
<masonf> s/other/others
<masonf> astearns: not sure why we'd follow the precedent of 4.
<masonf> ... is there a concern about Simon's concern about 100's of options. Could we say the listbox resizes indefinitely up to the screen height and no further?
<masonf> zcorpan: still a layout breaking change.
<lwarlow> q+
<masonf> astearns: possible for sure.
<masonf> ... choosing an arbitrary number is discoverability. Sometimes you can't tell it's scrollable. A default of 4.5 might therefore be more useful?
<astearns> ack astearns
<astearns> ack keithamus
<masonf> keithamus: I agree with Simon that the reasons we should have auto is that there won't be the same people doing CSS and HTML.
<masonf> ... if I'm not mistaken, height of auto would be the first form control that does that? Makes it a little weird? When they're in a form with other things?
<masonf> ... textarea also has an arbitrary height, and we seem fine with that. I'm also fine with constrained height here.
<astearns> ack lwarlow
<masonf> lwarlow: I don't particularly mind 4. We have it for textarea, it's probably fine.
<masonf> ... I don't buy that we can't do it because someone else writes the CSS. If I let people write my CSS they can already break my site. e.g. field-sizing: content.
<masonf> keithamus: select multiple is overlooked.
<masonf> zcorpan: it's expected with field-sizing: content. That's what it's for. But select has two different widgets. appearance:base is about being able to style it, not change the default height.
<masonf> lwarlow: it would change the height, but maybe not enough to break things.
<masonf> zcorpan: not from 4 lines to the whole screen.
<masonf> lwarlow: fair.
<lwarlow> 4 lines, ship it.
<masonf> astearns: approaching consensus on a height of 4 options, approximated as much as we can.
<masonf> ?
<keithamus> +1
<zcorpan> +1
<masonf> jarhar: hopefully so
<masonf> astearns: that's option 2 right?
<masonf> zcorpan: I'd prefer option 3
<masonf> astearns: only use 4 if size attr can't be parsed
<masonf> zcorpan: or if absent
<lwarlow> +1 option 3 is acceptable.
<masonf> astearns: any objections to option 3?
<masonf> +1 to option 3
<keithamus> +1 2 3
<jarhar> proposed resolution: choose option 3 which uses the size attribute
<masonf> RESOLVED: choose option 3 which uses the size attribute
Here are the latest proposed UA styles with the latest resolution:
select {
overflow: auto;
display: inline-block;
border: 1px solid currentColor;
box-sizing: border-box;
/* Use decision from here for field-sizing when that happens:
* https://github.com/w3c/csswg-drafts/issues/11838 */
block-size: calc(max(24px, 1lh) * attr(size type(<integer>), 4));
}
I probably won't be at the meeting, but here are my thoughts:
My main gripe is this: block-size: calc(max(24px, 1lh) * attr(size type(<integer>), 4));
I think defaulting to 4 is a bad idea. By default, listboxes should get their sizes from its contents (e.g. the height of the options), pretty much like how <div> grows as you add content. Listboxes should only get a fixed height if the size attribute is specified.
calc(max(24px, 1lh) * attr(size type(<integer>) should maybe be defined as a presentational hint from HTML.
In general, the spirit of appearance: base is that form controls should try to behave as plain <div> elements to the extent reasonable,
cc @lukewarlow @fantasai @annevk
Listboxes should only get a fixed height if the size attribute is specified.
Right now, this is only possible with the multiple attribute since the only way to get a listbox with a single-select is to use the size attribute. If in the future we added a new value for the size attribute or some other way of opting into listbox rendering, then we could address this, and/or we could make it so multiple with no size attribute is infinitely tall.
How about this?
select[size] {
block-size: calc(max(24px, 1lh) * attr(size type(<integer>)));
}
The CSS Working Group just discussed [css-forms-1] UA styles for base appearance listbox select elements.
The full IRC log of that discussion
<masonf> jarhar: last time we talked about the block size with the calc expression, approx to set height to number of elements in size attr<masonf> ...Tim left feedback that listbox should grow to fit if no size attr
<masonf> ...we could do that with size attr selector on the block-size property. Thoughts?
<emilio> q+
<masonf> astearns: what we did last time, if there's a size attr. What about if no size?
<masonf> jarhar: grow to fit all contents
<astearns> ack emilio
<masonf> emilio: feels weird that select multiple with appearance base and single option, height is height of option. If size=1 then grow to 24px.
<masonf> ...should we add a min-height: 24px?
<masonf> ...I'm with Tim, let's avoid magic
<masonf> ...someone will have an option with height>line-height, things get cropped.
<masonf> ...if author is responsible for that rule, ok. If UA rule, it's worse.
<masonf> ...too magic for my taste, but maybe ok.
<masonf> annevk: we could also not honor size attr.
<masonf> emilio: that's what Tim wants
<masonf> fantasai: he's arguing only when it's there, no default
<masonf> emilio: prefer not to honor it
<masonf> fantasai: we're struggling to define it, so why leave it to authors. Let's do it right.
<masonf> ...create UA magic if that's the right thing.
<masonf> ...author can't do that, would need JS
<masonf> emilio: point of appearance:base is to have as little magic as possible.
<masonf> fantasai: true. But it can be overridable. Goal is stylable form control. If sizing behavior you want needs magic, but easy to override, fine.
<masonf> ...we should figure out a reasonable way to get the right sizing behavior, but make it easy to override.
<masonf> emilio: but height doesn't seem right. Tons of edge cases. Is this more similar to line-clamp?
<masonf> ...can we line clamp without ellipsis? It's like that without the ellipsis.
<masonf> fantasai: that's max-lines property
<masonf> emilio: that digs into nested blocks {missed}
<masonf> zcorpan: good enough to use max-height?
<masonf> ...still concerned about select multiple without size and many options. For sites that get appearance:base from a stylesheet they don't control.
<masonf> fantasai: if they get appearance:base without expecting it, they're already in trouble.
<masonf> ...not concerned about not having a default size. But don't want to ignore the size attribute completely, because it's tricky.
<masonf> ...how does it work today?
<masonf> jarhar: in Chrome, iterate through every option in listbox. Figure out which is the tallest, multiply by size attr, that's the overall size.
<masonf> ...won't work for base appearance. Funny things like circular layout, etc.
<masonf> emilio: size works fine today, but limited today. Options are just text.
<zcorpan> https://html.spec.whatwg.org/#the-select-element-2:~:text=box%2E-,When,size%2E
<masonf> ...as soon as you have non-uniform options, things break. Multiple lines of text, e.g. 1lh stops working
<masonf> fantasai: when you have size=4, not getting exactly 4 because non-uniform, seems fine. If you have uniform items, it should roughly work.
<masonf> ...author not getting exactly 4, unless it's uniform, that seems fine.
<masonf> emilio: current proposal doesn't achieve that. Simple listbox with small subtitle underneath, all uniform. Or with padding. All of those break.
<masonf> ...lh-based size attr isn't great.
<masonf> ...we may as well multiply by 24px fixed.
<masonf> ...for anything complicated, equally broken.
<masonf> ...options are blocks, right? If we force options to be block formatting contexts, which seems ok, then max-lines does the trick, doesn't it?
<masonf> ...nested block is aligned
<masonf> ...for uniform options, that works. If you have a top option that's taller, it'll be weird when you scroll, but maybe ok.
<fantasai> "Only lines boxes in the same Block Formatting Context are counted: the contents of descendants that establish independent formatting contexts are skipped over while counting line boxes."
<masonf> fantasai: right now, spec'd - independent formatting contexts are skipped. If we instead count as a single line, that would work.
<masonf> emilio: that existing thing seems really bad anyway
<masonf> fantasai: maybe not web compat, but if we could make them count as a line, that would work here, but generally more useful.
<masonf> s/but generally/but also generally
<masonf> emilio: nice to see how size attr maps to max-lines
<masonf> astearns: this seemed like a small issue, but maybe it wasn't so small. Take back to the issue, to discuss max-lines?
<masonf> jarhar: I just searched CSS max-lines, and I don't think I found it. Can someone point me to that?
<masonf> fantasai: overflow-4
<masonf> emilio: supposed to be line-clamp would be max-lines something something ellipsis
<masonf> ?!
<masonf> ...it does the thing we want here - clamping the block. But we need to change how it skips nested ifc's
<masonf> astearns: separate issue for definition of max-lines?
<masonf> fantasai: I can open one
<masonf> astearns: see if the definition does what we want here, and fix it if not, and then bring it back here?
<masonf> ...but back to Simon's concern about multi-select with no size attr
<masonf> ...anything for base appearance that can set a max-height? Or should we?
<masonf> jarhar: Tim was arguing to fit contents. I don't have a strong opinion. Following the existing thing seemed to make sense. Also did infinitely tall all the time.
<masonf> jarhar: current behavior is a hard-coded size=4
<masonf> zcorpan: if select multiple isn't well used, then maybe ok
<fantasai> https://github.com/w3c/csswg-drafts/issues/12962
<masonf> zcorpan: if better default, could live with it
<emilio> test-case: data:text/html,<div style="display: -webkit-box; -webkit-box-orient: vertical; overflow: hidden; -webkit-line-clamp: 4"><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div
<emilio> style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div></div>
<masonf> zcorpan: they'd also have to use appearance:base, which will happen more over time
<emilio> It does indeed not clamp :')
<masonf> zcorpan: maybe rarely used enough that it's ok to change behavior
<masonf> emilio: ignore thing matches webkit-line-clamp, which is sad. Makes it harder.
<masonf> fantasai: compat issue then.
<masonf> ...we can evaluate how much compat impact. We can also check if there's a syntactic switch where line-clamp ignores, but max-lines doesn't.
<masonf> emilio: needs some design if there's a compat issue. Check with Andreu and Florian.
<fantasai> s/check if there's/consider adding/
<masonf> astearns: so do some investigation and come back here?
<masonf> jarhar: works fo rme
<masonf> s/fo rme/for me
<masonf> fantasai: if we don't find immediate compat answers, we might need help with use counter
<masonf> emilio: use counter doesn't seem trivial here. Can use count whether clamping changes, but not whether it's better or worse.
<masonf> ...easy to put behind a flag and experiment
The CSS Working Group just discussed [css-forms-1] UA styles for base appearance listbox select elements, and agreed to the following:
-
RESOLVED: with base appearance and no size attribute, the select element will be sized to fit its contents
The full IRC log of that discussion
<masonf> astearns: no change gives us the height of the content result. Is that what's currently spec'd?<masonf> jarhar: html says height of select multiple without size is "4".
<masonf> ...UA styles that I proposed 2 weeks ago size defaults to 4 in calculating height. Other one from an hour ago: put an attr selector so it grows to fit contents.
<masonf> astearns: don't fall back to 4?
<masonf> jarhar: yes, I think that's what Tim requested.
<masonf> astearns: Simon, you're ok with sizing to contents, given small usage of multi-select and appearance:base
<masonf> zcorpan: yes. Usage of appearance:base doesn't matter. But select-multiple is low regardless.
<masonf> astearns: Elika you're suggesting to leave things as they are, given we're adding size selector, and if no size attr, size to contents?
<masonf> fantasai: yeah
<masonf> astearns: sound ok to everyone?
<fantasai> PROPOSED: If no size attribute, <select multiple> has no fixed height.
<masonf> annevk: only the latter bit, right?
<zcorpan> https://chromestatus.com/metrics/feature/timeline/popularity/2857 ?
<masonf> astearns: intent is that with base appearance and no size attribute, multi-select sizes to fit its contents.
<jarhar> proposed resolution: with base appearance and no size attribute, the select element will be sized to fit its contents
<masonf> RESOLVED: with base appearance and no size attribute, the select element will be sized to fit its contents
@emilio I wasn't following along very well with the discussion about max-lines, could you share what properties would get the desired behavior?
@fantasai what is missing from max-lines behavior to achieve this?
I tried out some of the properties with the experimental implementation in chromium, and the container was sized correcly but when I scroll down to see more content, the subsequent elements were not rendered as if they were visibility: hidden:
<div id=container>
<div>one</div>
<div>two</div>
<div>three</div>
<div>four</div>
<div>five</div>
</div>
<style>
#container {
max-lines: 3;
block-ellipsis: no-ellipsis;
continue: collapse;
overflow: auto;
}
#container > div {
padding: 2px;
border: 2px solid black;
}
</style>
@dbaron do you have any opinions on using max-lines for this?
@josepharhar max-lines alone would do what we want for that simple test-case afaict. The main issue is that, if the inner <div>s (the <option>s) aren't treated atomically, it won't do the right thing for something like:
<div id=container>
<div>Title 1<br><em>subtitle</em></div>
<div>Title 2<br><em>subtitle</em></div>
...
</div>
For that to work right, you'd need something like:
#container > div {
display: flow-root;
}
Plus the fix discussed in the call (treating nested block-level formatting contexts as their own line).
For that to work right, you'd need something like:
#container > div { display: flow-root; }
Option elements already have display:flex for base appearance for ::checkmark. I'm guessing flow-root would make it not a flexbox anymore?
The proposed calc() for block-size fits options correctly as long as they are one line and the padding isn't changed - you can change the font-size to something that makes it bigger than 24px.
Even if calc() isn't perfect when the option has multiple lines or custom padding, I think that's ok. I don't believe that this is something authors will care much about since libraries (which I could find in a few minutes) don't offer a way to set the height to a specific number of options:
- https://material.angular.dev/cdk/listbox/overview
- https://primereact.org/listbox/
- https://react-spectrum.adobe.com/react-aria/ListBox.html
I also echo what Mason said in the last meeting, which is that most listboxes I see on the web aren't sized to fit an exact number of options and that it helps to indicate that it is scrollable.
display: flex would work just fine as well since it forms an independent formatting context.
So we have a variety of options for sizing listboxes with base appearance:
- Ignore the size attribute and allow the select to grow to fit its contents.
- Pros: allows developers to easily override height and doesn't require any magic.
- Cons: particular number given to the size attribute doesn't influence the height.
- Use a calc() expression
- Pros: allows developers to easily override height and doesn't require any magic.
- Cons: When options have more that one line of content or custom padding, then height won't perfectly match a specific number of options.
- Set line-clamp (max-lines) based on size attribute
- Pros: always sets height perfectly however options are rendered
- Cons:
- Unclear if its easy for authors to override the height by manually setting the height attribute.
- Can't prototype due to lack of implementation; I got feedback that it won't be ready for a while.
- Diverging proposals for this property in different levels of the spec.
- Use intrinsic sizing
- Pros: allows developers to easily override height and always sets height perfectly however options are rendered
- Cons:
- Might not be easy to explain how this works given existing features.
- I've heard that there might be circularity issues, but I don't have an example.
I believe that using calc() is best because it allows the size attribute to do something, and if it doesn't perfectly match a number of options that is OK because sizing listboxes to fit an exact number of options is not a typical use case.
I'm also ok with options 1 and 4, but I'd prefer not to use line-clamp because of:
- the outstanding issues that will make it very hard for me to use
- if it makes the height property stop working, it will be a major annoyance for developers
- as I mentioned in the last point, making it perfectly size interesting options in all cases is not a typical or important use case.
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.
The full IRC log of that discussion
<cwilso> Topic: sizing base appearance listbox: w3c/csswg-drafts#12510<cwilso> https://github.com/w3c/csswg-drafts/issues/12510
<dbaron> github: https://github.com/w3c/csswg-drafts/issues/12510
<cwilso> Github: https://github.com/w3c/csswg-drafts/issues/12510
<cwilso> scribe+
<cwilso> jarhar: want to size listboxes with the size attribute. Listed four options:
<cwilso> ...1: height will just be how many options there are, and height set on them.
<cwilso> ...2: calc exporession to estimate height of each options, and use adder to size with UA style for height
<lea> q+
<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,.
<emilio> q+
<cwilso> ...4) write intrinsic sizing code that tries to do the same thing that mx lines should theoretically do.
<cwilso> fantasia: what's the issue with max lines?
<cwilso> jarhar: not clear if you set max lines and then set height, height will still override?
<cwilso> emilio: max onluy likes clamps.
<astearns> q+
<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,.
<masonf> q+
<cwilso> ...if we need something temporarily, we can do that.
<cwilso> ack lea
<emilio> ack emilio
<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
<cwilso> ... we should make this a conscious choice one way or another.
<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.
<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/
<astearns> ack astearns
<cwilso> ... i don't think that will cause a future compat issue.
<astearns> ack masonf
<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.
<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?
<lea> q?
<cwilso> emilio: doesn't seem like it's quite the same
<lea> q+ to +1 masonf's idea
<cwilso> ... max-lines changes how height auto behaves; not clear it would work that way.
<cwilso> mason: would be interesting to know how they differ
<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?
<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.
<astearns> My vote is to account for option height (as much as we can). Consistent sizing across selects seems much less useful
<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.
<cwilso> ack dbaron
<cwilso> ack lea
<Zakim> lea, you wanted to +1 masonf's idea
<emilio> q+
<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?
<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
<cwilso> ack emilio
<cwilso> emilio: max lines proposal would include counting block lines. Right now it doesn't include that behavior, but it would
<cwilso> ... so you wouldn't need to duplicate the padding, etc.
<cwilso> lea: this might be the right primitive then. But that doesn't mean we can't ship with magic first then change it.
<cwilso> s/change it/define in terms of max lines later
<cwilso> ack jarhar
<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?
<cwilso> jarhar: if 2we don't use max lines then height auto means?
<masonf> q+
<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.
<fantasai> https://github.com/w3c/csswg-drafts/issues/12962
<cwilso> emilio: max lines applies to boxes, so ...
<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
<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./
<emilio> s/boxes/blocks
<cwilso> fantasai: I filed this issue: what if instead of counting lines we got foreign independent formatting context?
<cwilso> ... s/foreign/for
<cwilso> ack fan
<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
<emilio> q+
<cwilso> ...if we expand max lines to do these kinds of things we can very easily have it solve this case.,
<lea> q+
<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.
<cwilso> ack mas
<cwilso> ack em
<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
<astearns> q+
<cwilso> emilio: compat-wise, there's no compat blocker because nobody ships max lines properly now.
<masonf> q+
<cwilso> ...problem with intrinsic size: how do you turn it off?
<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()
<cwilso> lea: I experimented and I cannot figure out what Chromium is doing with intrinsic size in this case.
<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()
<cwilso> ack lea
<cwilso> 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.
<cwilso> astearns: I'm slightly against using option with magic we intend to replace with max-lines
<lea> q?
<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.
<cwilso> ack as
<cwilso> ack ma
<cwilso> masonf: +1. usage of this control is almost zero today so there's still time.
<lea> q+
<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
<cwilso> emilio: yes that's true
<cwilso> fantasai: if max lines changes intrinsic height would that change min-content and max-content as well?
<cwilso> emilio: I forget the status
<cwilso> ack next
<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()
<emilio> q+
<cwilso> jarhar: two arguments in favor of calc: easier for authors to override with height:auto.
<cwilso> ...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...
<cwilso> emilio: if we go for calc, we are unlikely to move to anything else in the future.
<cwilso> ...not a fan of that. This is maybe special case enough, but I think it's the wrong decision
<cwilso> anne: how does this work with one option case?
<cwilso> emilio: one option tall
<lea> scribe+
<cwilso> ack next
<emilio> ack emilio
<lea> Lea: calc() with what inside?
<masonf> lea the proposal is roughly here: https://github.com/w3c/csswg-drafts/issues/12510#issuecomment-3411329283
<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.
<astearns> I am less optimistic that new magic will always be explainable
<jarhar> lea, it is this: block-size: calc(max(24px, 1lh) * attr(size type(<integer>), 4));
<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.
<cwilso> ack next
<lea> Lea: there are reasonable things to do w fewer options, e.g. use the mode or avg
<cwilso> fantasai: I think joey's point that if you only have one item max lines would give surprising behavior is compelling.
<jarhar> q?
<jarhar> q+
<masonf> straw poll?
<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.
<astearns> s/be explainable/be eventually explainable/
<lea> 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
<lea> 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
<cwilso> ack jarhar
<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
<lea> dbaron: These are not the only options though
<lea> Anyhow, D or B
<emilio> Preferred: B, Acceptable: A, C
<jarhar> A
<lea> scribe-
<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
<fantasai> s/dbaron:/dbaron,/
<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.)
<fantasai> s/fantasai/Joey/
<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
<lea> q+
<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.
<cwilso> RESOLVED: Go with A for now, investigate D as a future replacement.
<masonf> Great discussion on that.
<cwilso> jarhar: pinged ian and tab on next issue, they should reply soon.
<cwilso> rrsagent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2025/12/11-css-minutes.html cwilso
<cwilso> rrsagent, make log public
<RRSAgent> I have made the request, cwilso
For context "A" is calc(), "D" is instrinsic sizing or something like intrinsic sizing