Meeting minutes
<astearns> fantasai (or any other Apple folks) will you be joining the form controls meeting?
github-bot, take up w3c/
[selectors] Add pseudo-classes for `<select>` being a drop-down box vs a list box
<github-bot> OK, I'll post this discussion to https://
jarhar: There is an existing pseudo class for this in Chrome, and it'd be good to make that accessible to the web.
jarhar: This will be helpful for the next issue - defining styles for dropdown vs listbox
jarhar: Lea brought up that this means it won't be CSS-controllable to switch between listbox and dropdown. It'd be circular.
jarhar: I don't think it should be controllable via CSS, we should just expose the thing we already have.
jarhar: Two alternatives I saw: a has-picker() with the element, or select:has-picker
jarhar correct my naming please
lwarlow: could just be :has-picker, because people will put the element in the selector anyway
lwarlow: the compat problem here is different from the appearance:base problem
<lea> Yes, I think `select:has-picker(select)` looks very weird from an author pov
lwarlow: with this pseudo class, it's less important. It'd be nice to just use select:has-picker
lwarlow: perhaps you could do this in the future via CSS, if you have a rule that applies when the element renders
astearns: whatever method we use to switch, you're saying we could make the pseudo only apply when it renders?
lwarlow: maybe it only switches until the element renders, and then locks in until it stops rendering, to avoid circularity.
lwarlow: I don't like CSS for this anyway, but I'm saying this doesn't block it if we really want to in the future
lwarlow: appearance:base doesn't allow you to switch while the picker is open
lwarlow: having the switch in HTML makes sense, the size attribute makes sense
lwarlow: I like the :has-picker because it matches
lea: I'd support making this non-functional pseudo class
lea: seems weird to duplicate the element type
lea: very little precedent for selectors like this. Others are quite different.
lea: if this only works for select, we need something to not break compat. Can't it just work for all pickers?
lea: there is already showpicker. Perhaps we can just make it work?
lwarlow: showpicker is designed so that it doesn't reveal whether there's a picker
lwarlow: it also doesn't fully work in the web. E.g. ios webkit - only works for color picker. Or something else. But not all.
lwarlow: key reason is that detecting whether the picker opened is tough. I've implemented it but can't write tests.
lwarlow: :has-picker would have the same behavior/problem
lwarlow: it can work for base pickers - popovers are easy. But auto appearance pickers are tough
lwarlow: also a question about whether we want to expose that. If authors depend on needing a picker, it causes issues.
lwarlow: but select is different because both modes are specified and expected to exist
lea: stepping back, do we need a pseudo class at all?
lea: you can detect with attributes, and this is just making it easy. Maybe defer?
lea: all proposed solutions have problems. If single :has-picker, I'd expect it to work everywhere. Requiring an argument is weird. It could be :drop-down?
lea: if it doesn't work for appearance:auto, that would also be surprising.
<astearns> +1 to concern about this only work with appearance: base
lea: having css properties affect pseudo class matching is circular
una: It's a bit of an edge case to ship an entire pseudo class for this. The author knows whether there's a dropdown.
una: let's not call it drop-down by the way
una: we could debate the naming, but maybe let's not open that can of worms
una: can't you do this with style queries?
una: do we need to launch this now?
<Zakim> lea, you wanted to react to una
lea: with style queries you can only target the element not the descendants
una: author still has control
<lea> does it have a picker in iOS? Is that considered a picker?
lwarlow: to clarify - a select in dropdown mode always has a picker. Problem with auto appearance isn't there.
lwarlow: people might write styles that don't transfer - they need to know whether a picker actually opened
lwarlow: not queryable via style queries or attributes. E.g. size attribute with invalid value.
lwarlow: mobile browsers have a system where it's always a dropdown, even if you have size attributes, etc.
lwarlow: also useful to apply stylesheets in specs and browser implementations
masonf: why did we need it in the UA stylesheet
jarhar: I don't think we can use style queries to do this, but I don't know for sure. Gut says no.
una: Luke was talking about mobile not respecting size attribute. Is that what we're resolving here?
una: feels like something is unexpected with mobile browsers now, right?
jarhar: I'm planning to make a change to make it always the same across mobile and desktop
<Lwarlow> The solution would be this selector right?
una: this issue would be different in that case?
jarhar: I want the pseudo class so I can define different styles
jarhar: I Don't think there are selectors that can do the same thing
masonf: you can't match exactly what :has-picker does with just a selector
lwarlow: the other aspect other than invalid size. Even if queryable, there are a number of permutations in your stylesheet. No attributes, multiple attribute, size attribute, all permutations of those, etc.
lwarlow: I'm not sure we need to force browsers (from a spec perspective) to do something specific for appearance:auto
lwarlow: still value in having this pseudo in appearance:auto and base. E.g. what if you have mixed modes, base on the in-page, auto on the picker
lwarlow: each browser already has this, let's just expose it
lea: can't easily do this with style selectors, but solution isn't an ad-hoc selector
lea: if we add a pseudo class, it needs to match appearance:auto
<Lwarlow> But that still doesn’t solve the issue (but yes we should have that)
lea: I put a code snippet that shows circularity if you don't support appearance:auto
lea: you said browser doesn't know if it showed a picker
lea: for author code, you know what you have generally. I cannot think of use cases outside CSS frameworks and libraries, which can afford to have more complex selectors.
lea: so I think the motivation is too weak to justify the complexity involved
<jarhar> masonf: the selector is pretty complicated, so frameworks and libraries are an actual use case
<jarhar> masonf: its similar to ua stylesheets, its complicated enough that every browser has done it this way
<Lwarlow> It’s not even complicated it just isn’t possible…
<jarhar> masonf: it seems like the crux of this argument is
<jarhar> astearns: id like to see evidence that each browser does this
<jarhar> masonf: i think chromium and webkit have it
<jarhar> masonf: the selector youre talking about is complicated or currently impossible given the parsing rules for size, the selector is giant if it can be done
<jarhar> masonf: i think this comes down to naming or can it be done for everything
<jarhar> masonf: can we return to the question of making it work for everything that has a picker?
<una> +1
<jarhar> masonf: its not possible for a browser to know whether it tried to open a picker
<jarhar> masonf: this might be a corner case
<jarhar> masonf: maybe we could just do :has-picker and make it work everywhere
<lea> The only reason it's complicated today is that we can't just `[size > 0], [multiple]`, which doesn't seem that complicated?
lea: wanted to reply to the complex thing today. Reason is that we can't ... see comment
lea: can't do attribute values today, but if we could, then
fantasai: I don't think we should go down the generic :has-picker thing
fantasai: can we do that with pseudos
<lea> (that said making `:has()`work with pseudo-elements is also a common ask)
fantasai: we don't have a generic use case here. Select is particular in that it has two forms.
fantasai: let's do a specific select thing, therefore
fantasai: I can imagine styling differently if the picker is shown, but that would be :picker-shown
lwarlow: big +1 to that. Selector that just works for listbox vs. dropdown then that's great.
lwarlow: especially if we don't see this being useful for inputs. There might be cases, where inputs might or might not have a picker, but probably niche enough that we don't need it
lwarlow: :has-picker is doable, but :open isn't
lwarlow: timing is tough, but whether you try to open a picker isn't
lwarlow: :has-listbox is fine. Reason behind drop-down vs list-box isn't exposed in the platform
<lea> presumably `:listbox` , not `:has-listbox`?
lwarlow: should be listbox rather than dropdown, because dropdown is too overloaded
<masonf> +1 from the scribe for something like that also
annevk: I think for most other controls, you could use @supports with the picker pseudo element
annevk: with select, there are two types of controls, only one with a picker. So select is indeed special.
annevk: you can tell if it supports it, but not whether it'll show one
annevk: we haven't designed this part yet, maybe we should wait to define the rest first?
<lea> +1
annevk: one concern I heard with listboxes more generally, including on desktop. On macos, there's no native ... multi-select dropdowns.
annevk: That's a problem for trying to reconcile these things
<lea> Just to reply to Anne, select is the only control that has both a picker and in-page mode *currently*, but down the line we could end up with more. E.g. for date pickers at least, it has been brought up that being able to render them as an in-page calendar (possibly for use in a bigger control, like a date range control) could also be useful.
lea: for date pickers, it might be useful to render in the page.
<Lwarlow> Multiple dropdown basically is only a thing natively on iOS and android. So yeah that’s an issue
<lea> Lwarlow: What if it defaulted to appearance: base in platforms that don't support that? Since UAs have to implement that anyway
jarhar: I thought this would be easier. I could define this in the spec based on listbox mode, and keep the internal pseudo class in the impl.
github-bot, take up w3c/
[css-forms-1] UA styles for base appearance listbox select elements
<github-bot> OK, I'll post this discussion to https://
<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
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.
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
jarhar: I wrote a comment about 5 styles that should apply (commented on the issue).
jarhar: overflow, border, display, and user-select
jarhar: what do you think?
lea: one requirement - it should be possible to size intrinsically to fit the contents.
lea: seems like it should be possible, just don't want to lose track of this
lea: once you can style them, you've got flexibility to change the appearance a lot. All of these require no scrolling.
lea: 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"
lea: if you say size:3 it doesn't do 3 lh's it says three options
lea: however tall three options are. Not sure this is useful, but maybe.
una: generally these look good. I'm always a fan of simplicity. Fewer things for authors to override.
una: I noticed padding block and inline that was removed. Why remove padding and gaps and things?
jarhar: I think the padding and gaps are to space the content inside the button, so the picker icon has space.
jarhar: and to make sure text inside the button is spaced away from edges. With listbox, that doesn't apply.
jarhar: option elements will already have those rules, and the options will fill the select.
una: makes sense
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.
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.
lwarlow: don't need to opt in to field-sizing: content
lwarlow: only reason this isn't used more is that it isn't implemented everywhere
lwarlow: other than that, these styles make sense
lwarlow: don't think it should have border or border radius
lwarlow: just matching everything else makes sense. Should be box-sizing:border-box maybe?
lwarlow: not having overflow:scroll is good. That's odd currently.
lea: I agree with not having border radius, and generally the fewer styles the better.
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.
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?
lea: agree that most authors want to set max height. Do we really need field-sizing, and !important?
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.
lwarlow: question about form controls having special behavior in base appearance mode
lwarlow: there's a CSS issue discussing this
lwarlow: some people might like select's fixed behavior, automatically sizing based on longest option
lea: I was reading the select styles, they do make sense for drop downselect, I just meant for listboxes
lwarlow: don't need the !important, that's likely an impl detail
lwarlow: you can't do fixed sizing width-wise, and no easy way height-wise. Might be that we can't allow fixed mode.
lea: we could also say field-sizing always resolves to content in appearance base or something
lea: I was expecting flex, but you have inline-block. Authors can override.
lea: do browsers use flex or something else?
jarhar: picker with select is a flexbox, I'd imagine it's the same here for listbox right?
jarhar: customizable-select picker is display:block
lwarlow: we probably need a wider discussion of the display value in appearance:base.
lwarlow: maybe it doesn't matter much here, but matters more in other controls
<lea> (also fewer things for authors to override)
lwarlow: we should be consistent. Maybe select is special.
ntim: one goal for appearnace:base is to make it as close to a plain div as possible.
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
ntim: want to solve this generally
ntim: maybe new field-sizing:auto value?
astearns: want to reduce the number of author overrides, vs having it be close to a div. Those are in tension.
astearns: need extra justification for things that make things more complicated for bare div
ntim: from perspective of a new author, wondering why form controls behave differently. Try to fix with appearance:base
astearns: we have these two sets of styles, but no way (yet) to decide between them
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 switch.
astearns: we can move forward with these rules and have UA magic make them apply
annevk: to be clear, I wasn't against exposing it, just wanted it to be consistent
annevk: seems like some pseudo class is warranted.
astearns: take this back to the issue, debate the things we didn't decide today