- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Oct 2025 15:29:05 +0000
- To: public-css-archive@w3.org
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`
<details><summary>The full IRC log of that discussion</summary>
<masonf> scribenick: masonf<br>
<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.<br>
<masonf> ... dbaron had an idea for using calc to scale with the line height. I also posted a few other options.<br>
<masonf> ... I tried implementing the calc expression and I think it works fairly well. Might not match HTML spec.<br>
<masonf> ...thought about it more, it's likely ok. The place where they mismatch is likely funny edge cases like size=123abc<br>
<masonf> ...you might not get the height you expect, but it's an error anyway, and not common.<br>
<masonf> ...many authors likely explicitly set the size of the box anyway.<br>
<masonf> ...I like the calc expression with the attr(). Any other thoughts?<br>
<lwarlow> q+<br>
<masonf> lwarlow: I'm between option 1 and some form of option 2.<br>
<masonf> ... I think most people like field sizing, and don't want the fixed size in html thing.<br>
<masonf> ... generally that's for textarea but the same thing likely applies to select.<br>
<keithamus> q+<br>
<astearns> ack lwarlow<br>
<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?<br>
<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.<br>
<masonf> ... I wouldn't bother with option 3. Likely to not be correct.<br>
<masonf> ... I lean toward option 1, lean to option 2<br>
<astearns> ack keithamus<br>
<astearns> s/lean to option 2/OK with option 2/<br>
<masonf> keithamus: if min/max would have been invented before min-height, we wouldn't have added it. I disagree with using min-height.<br>
<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.<br>
<masonf> ... this {not sure which option "this" refers to} is the most reasonable.<br>
<masonf> jarhar: do you like option 3 with attr(size) or option 2 that doesn't.<br>
<masonf> keithamus: I think attr(size) makes a lot of sense.<br>
<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.<br>
<masonf> s/karhar/jarhar<br>
<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.<br>
<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.<br>
<masonf> ... same reason why aria-level starts at 2. Why?<br>
<masonf> (because... history)<br>
<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.<br>
<masonf> lwarlow: but we use that to switch modes.<br>
<masonf> dbaron: ahh the fallback to 4 is just when the size doesn't parse.<br>
<masonf> jarhar: or when you put `multiple` on it<br>
<masonf> dbaron: maybe what I said works then.<br>
<lwarlow> Fwiw the default is approximately 4 options show today<br>
<masonf> zcorpan: current behavior is to show 4 rows.<br>
<masonf> dbaron: the non-base appearance you mean<br>
<masonf> zcorpan: yes<br>
<masonf> zcorpan: seems reasonable to match that<br>
<masonf> astearns: but base appearance is to fix historical things, so we shouldn't blindly copy that.<br>
<masonf> jarhar: we can do infinitely tall then. Makes sense to use 4 if there's no better number.<br>
<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?<br>
<masonf> jarhar: two lines?<br>
<masonf> keithamus: rich option with two lines. Label and description of label. Each option takes up 2 lines.<br>
<lwarlow> Yes it's true in all desktop browsers that a listbox defaults to "4"<br>
<masonf> keithamus: it's a default, but in this case it's not a useful default.<br>
<masonf> jarhar: if more than 24px tall then you'd just see 2 options.<br>
<masonf> q+<br>
<lwarlow> q+<br>
<masonf> keithamus: are there examples?<br>
<masonf> lwarlow: usage is low<br>
<astearns> masonf: yes, usage is low<br>
<jarhar> masonf: usage is very low<br>
<jarhar> masonf: these are just defaults<br>
<jarhar> masonf: like the old thing, it should just kind of work<br>
<astearns> ack masonf<br>
<jarhar> masonf: if the dev wants the new thing, theyll probably size it<br>
<jarhar> masonf: theyll set a height relative to the page, or calculate it themselves since they know whats in their options<br>
<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<br>
<masonf> thanks for minuting jarhar<br>
<astearns> ack lwarlow<br>
<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?<br>
<zcorpan> q+<br>
<masonf> lwarlow: might be better behavior. If you want to override, you can.<br>
<astearns> q+<br>
<masonf> ... yes it's just a default, but having a default where it's arbitrary 4 is weird.<br>
<masonf> ... makes sense for a textarea, because you want to see things. Doesn't make much sense here.<br>
<masonf> ... it would grow, if you increase the font size. lh will increase.<br>
<masonf> ... if you're doing formatting such that line height doesn't match the height. E.g. padding.<br>
<keithamus> q+<br>
<masonf> ... does the size attribute for that make sense? Using lh might not make sense.<br>
<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.<br>
<astearns> ack zcorpan<br>
<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.<br>
<masonf> ... wordpress themes that are reset stylesheets used on 1000's of sites.<br>
<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.<br>
<masonf> ... having some consistency with current behavior makes sense. But of course be able to override.<br>
<masonf> astearns: I like option 1 better than the other.<br>
<masonf> s/other/others<br>
<masonf> astearns: not sure why we'd follow the precedent of 4.<br>
<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?<br>
<masonf> zcorpan: still a layout breaking change.<br>
<lwarlow> q+<br>
<masonf> astearns: possible for sure.<br>
<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?<br>
<astearns> ack astearns<br>
<astearns> ack keithamus<br>
<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.<br>
<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?<br>
<masonf> ... textarea also has an arbitrary height, and we seem fine with that. I'm also fine with constrained height here.<br>
<astearns> ack lwarlow<br>
<masonf> lwarlow: I don't particularly mind 4. We have it for textarea, it's probably fine.<br>
<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.<br>
<masonf> keithamus: select multiple is overlooked.<br>
<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.<br>
<masonf> lwarlow: it would change the height, but maybe not enough to break things.<br>
<masonf> zcorpan: not from 4 lines to the whole screen.<br>
<masonf> lwarlow: fair.<br>
<lwarlow> 4 lines, ship it.<br>
<masonf> astearns: approaching consensus on a height of 4 options, approximated as much as we can.<br>
<masonf> ?<br>
<keithamus> +1<br>
<zcorpan> +1<br>
<masonf> jarhar: hopefully so<br>
<masonf> astearns: that's option 2 right?<br>
<masonf> zcorpan: I'd prefer option 3<br>
<masonf> astearns: only use 4 if size attr can't be parsed<br>
<masonf> zcorpan: or if absent<br>
<lwarlow> +1 option 3 is acceptable.<br>
<masonf> astearns: any objections to option 3?<br>
<masonf> +1 to option 3<br>
<keithamus> +1 2 3<br>
<jarhar> proposed resolution: choose option 3 which uses the size attribute<br>
<masonf> RESOLVED: choose option 3 which uses the size attribute<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-3361831625 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 October 2025 15:29:06 UTC