- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 24 Jul 2025 15:59:19 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-forms-1] UA styles for base appearance listbox select elements`. <details><summary>The full IRC log of that discussion</summary> <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.<br> <fantasai> in many form controls the picker is an optional aid, not the core part of the control<br> <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.<br> <lea> q+<br> <lea> q-<br> <masonf> jarhar: I think this is easy, compared to single-select, since it's just removing some things like button styles.<br> <Lwarlow> Yeah the embedded vs in page with optional picker is interesting<br> <lea> q+<br> <masonf> jarhar: I wrote a comment about 5 styles that should apply (commented on the issue).<br> <masonf> jarhar: overflow, border, display, and user-select<br> <masonf> jarhar: what do you think?<br> <astearns> ack lea<br> <una> q+<br> <masonf> lea: one requirement - it should be possible to size intrinsically to fit the contents.<br> <masonf> lea: seems like it should be possible, just don't want to lose track of this<br> <masonf> lea: once you can style them, you've got flexibility to change the appearance a lot. All of these require no scrolling.<br> <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.<br> <masonf> lea: if you say size:3 it doesn't do 3 lh's it says three options<br> <masonf> lea: however tall three options are. Not sure this is useful, but maybe.<br> <astearns> ack una<br> <Lwarlow> Q+<br> <masonf> una: generally these look good. I'm always a fan of simplicity. Fewer things for authors to override.<br> <masonf> una: I noticed padding block and inline that was removed. Why remove padding and gaps and things?<br> <masonf> jarhar: I think the padding and gaps are to space the content inside the button, so the picker icon has space.<br> <masonf> jarhar: and to make sure text inside the button is spaced away from edges. With listbox, that doesn't apply.<br> <lea> q+<br> <masonf> jarhar: option elements will already have those rules, and the options will fill the select.<br> <masonf> una: makes sense<br> <astearns> ack Lwarlow<br> <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.<br> <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.<br> <masonf> lwarlow: don't need to opt in to field-sizing: content<br> <masonf> lwarlow: only reason this isn't used more is that it isn't implemented everywhere<br> <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"/<br> <masonf> lwarlow: other than that, these styles make sense<br> <masonf> lwarlow: don't think it should have border or border radius<br> <masonf> lwarlow: just matching everything else makes sense. Should be box-sizing:border-box maybe?<br> <masonf> lwarlow: not having overflow:scroll is good. That's odd currently.<br> <astearns> ack lea<br> <masonf> lea: I agree with not having border radius, and generally the fewer styles the better.<br> <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.<br> <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?<br> <masonf> lea: agree that most authors want to set max height. Do we really need field-sizing, and !important?<br> <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<br> <lea> also just realized I was reading the select styles as listbox styles.<br> <masonf> lwarlow: question about form controls having special behavior in base appearance mode<br> <masonf> lwarlow: there's a CSS issue discussing this<br> <masonf> lwarlow: some people might like select's fixed behavior, automatically sizing based on longest option<br> <masonf> lea: I was reading the select styles, they do make sense for drop downselect, I just meant for listboxes<br> <lea> q+<br> <masonf> lwarlow: don't need the !important, that's likely an impl detail<br> <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.<br> <masonf> lea: we could also say field-sizing always resolves to content in appearance base or something<br> <masonf> lea: I was expecting flex, but you have inline-block. Authors can override.<br> <masonf> lea: do browsers use flex or something else?<br> <masonf> jarhar: picker with select is a flexbox, I'd imagine it's the same here for listbox right?<br> <masonf> jarhar: customizable-select picker is display:block<br> <Lwarlow> Q+<br> <astearns> ack lea<br> <astearns> ack Lwarlow<br> <masonf> lwarlow: we probably need a wider discussion of the display value in appearance:base.<br> <ntim> q+<br> <masonf> lwarlow: maybe it doesn't matter much here, but matters more in other controls<br> <lea> (also fewer things for authors to override)<br> <masonf> lwarlow: we should be consistent. Maybe select is special.<br> <astearns> ack ntim<br> <masonf> ntim: one goal for appearnace:base is to make it as close to a plain div as possible.<br> <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<br> <masonf> ntim: want to solve this generally<br> <masonf> ntim: maybe new field-sizing:auto value?<br> <masonf> astearns: want to reduce the number of author overrides, vs having it be close to a div. Those are in tension.<br> <masonf> astearns: need extra justification for things that make things more complicated for bare div<br> <masonf> ntim: from perspective of a new author, wondering why form controls behave differently. Try to fix with appearance:base<br> <masonf> astearns: we have these two sets of styles, but no way (yet) to decide between them<br> <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.<br> <masonf> s/swithc/switch<br> <masonf> astearns: we can move forward with these rules and have UA magic make them apply<br> <masonf> annevk: to be clear, I wasn't against exposing it, just wanted it to be consistent<br> <masonf> annevk: seems like some pseudo class is warranted.<br> <masonf> astearns: take this back to the issue, debate the things we didn't decide today<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-3114014396 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 24 July 2025 15:59:20 UTC