14:58:31 <RRSAgent> RRSAgent has joined #css
14:58:36 <RRSAgent> logging to https://www.w3.org/2025/07/24-css-irc
14:58:36 <Zakim> RRSAgent, make logs Public
14:58:37 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:01:04 <jarhar> jarhar has joined #css
15:01:31 <lea> lea has joined #css
15:01:41 <lea> present+
15:01:45 <masonf> masonf has joined #css
15:02:04 <Lwarlow> Lwarlow has joined #css
15:02:11 <masonf> scribenick: masonf
15:04:00 <astearns> fantasai (or any other Apple folks) will you be joining the form controls meeting?
15:06:41 <masonf> github-bot, take up https://github.com/w3c/csswg-drafts/issues/7422
15:06:41 <github-bot> Topic: [selectors] Add pseudo-classes for `<select>` being a drop-down box vs a list box
15:06:41 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7422.
15:07:11 <masonf> jarhar: There is an existing pseudo class for this in Chrome, and it'd be good to make that accessible to the web.
15:07:21 <Lwarlow> Q+
15:07:25 <masonf> jarhar: This will be helpful for the next issue - defining styles for dropdown vs listbox
15:07:47 <masonf> jarhar: Lea brought up that this means it won't be CSS-controllable to switch between listbox and dropdown. It'd be circular.
15:08:00 <masonf> jarhar: I don't think it should be controllable via CSS, we should just expose the thing we already have.
15:08:22 <masonf> jarhar: Two alternatives I saw: a has-picker() with the element, or select:has-picker
15:08:26 <astearns> ack Lwarlow
15:08:31 <masonf> jarhar correct my naming please
15:09:01 <masonf> lwarlow: could just be :has-picker, because people will put the element in the selector anyway
15:09:13 <masonf> lwarlow: the compat problem here is different from the appearance:base problem
15:09:25 <lea> Yes, I think `select:has-picker(select)` looks very weird from an author pov
15:09:26 <lea> q?
15:09:36 <masonf> lwarlow: with this pseudo class, it's less important. It'd be nice to just use select:has-picker
15:10:01 <masonf> lwarlow: perhaps you could do this in the future via CSS, if you have a rule that applies when the element renders
15:10:38 <masonf> astearns: whatever method we use to switch, you're saying we could make the pseudo only apply when it renders?
15:11:04 <masonf> lwarlow: maybe it only switches until the element renders, and then locks in until it stops rendering, to avoid circularity.
15:11:16 <masonf> 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
15:11:30 <masonf> lwarlow: appearance:base doesn't allow you to switch while the picker is open
15:11:48 <lea> q+
15:11:52 <masonf> lwarlow: having the switch in HTML makes sense, the size attribute makes sense
15:12:00 <masonf> lwarlow: I like the :has-picker because it matches
15:12:01 <astearns> ack lea
15:12:14 <masonf> lea: I'd support making this non-functional pseudo class
15:12:20 <masonf> lea: seems weird to duplicate the element type
15:12:33 <masonf> lea: very little precedent for selectors like this. Others are quite different.
15:12:48 <masonf> lea: if this only works for select, we need something to not break compat. Can't it just work for all pickers?
15:12:58 <Lwarlow> Q+
15:13:04 <masonf> lea: there is already showpicker. Perhaps we can just make it work?
15:13:11 <astearns> ack Lwarlow
15:13:22 <masonf> lwarlow: showpicker is designed so that it doesn't reveal whether there's a picker
15:13:45 <masonf> 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.
15:14:00 <lea> q+
15:14:06 <masonf> lwarlow: key reason is that detecting whether the picker opened is tough. I've implemented it but can't write tests.
15:14:20 <masonf> lwarlow: :has-picker would have the same behavior/problem
15:14:48 <masonf> lwarlow: it can work for base pickers - popovers are easy. But auto appearance pickers are tough
15:15:20 <masonf> lwarlow: also a question about whether we want to expose that. If authors depend on needing a picker, it causes issues.
15:15:22 <una> una has joined #css
15:15:29 <una> present+
15:15:36 <masonf> lwarlow: but select is different because both modes are specified and expected to exist
15:15:38 <astearns> ack lea
15:15:49 <masonf> lea: stepping back, do we need a pseudo class at all?
15:16:04 <masonf> lea: you can detect with attributes, and this is just making it easy. Maybe defer?
15:16:09 <una> q+
15:16:35 <masonf> 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?
15:16:44 <masonf> lea: if it doesn't work for appearance:auto, that would also be surprising.
15:16:51 <astearns> +1 to concern about this only work with appearance: base
15:17:02 <masonf> lea: having css properties affect pseudo class matching is circular
15:17:11 <astearns> ack una
15:17:18 <Lwarlow> Q+
15:17:32 <masonf> 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.
15:17:40 <masonf> una: let's not call it drop-down by the way
15:17:55 <masonf> una: we could debate the naming, but maybe let's not open that can of worms
15:18:02 <masonf> una: can't you do this with style queries?
15:18:14 <masonf> una: do we need to launch this now?
15:18:18 <masonf> q+
15:18:18 <lea> qq+
15:18:24 <astearns> ack lea
15:18:24 <Zakim> lea, you wanted to react to una
15:18:44 <masonf> lea: with style queries you can only target the element not the descendants
15:18:49 <masonf> una: author still has control
15:18:53 <astearns> ack Lwarlow
15:19:10 <lea> does it have a picker in iOS? Is that considered a picker?
15:19:25 <masonf> lwarlow: to clarify - a select in dropdown mode always has a picker. Problem with auto appearance isn't there.
15:19:42 <masonf> lwarlow: people might write styles that don't transfer - they need to know whether a picker actually opened
15:20:10 <masonf> lwarlow: not queryable via style queries or attributes. E.g. size attribute with invalid value.
15:20:31 <masonf> lwarlow: mobile browsers have a system where it's always a dropdown, even if you have size attributes, etc.
15:20:53 <masonf> lwarlow: also useful to apply stylesheets in specs and browser implementations
15:21:02 <una> q+
15:21:27 <masonf> masonf: why did we need it in the UA stylesheet
15:21:41 <masonf> jarhar: I don't think we can use style queries to do this, but I don't know for sure. Gut says no.
15:21:52 <astearns> ack masonf
15:22:09 <masonf> una: Luke was talking about mobile not respecting size attribute. Is that what we're resolving here?
15:22:20 <masonf> una: feels like something is unexpected with mobile browsers now, right?
15:22:51 <masonf> jarhar: I'm planning to make a change to make it always the same across mobile and desktop
15:22:54 <Lwarlow> The solution would be this selector right?
15:23:02 <masonf> una: this issue would be different in that case?
15:23:12 <masonf> q+
15:23:24 <astearns> ack una
15:23:24 <lea> q?
15:23:35 <masonf> jarhar: I want the pseudo class so I can define different styles
15:23:46 <lea> q+
15:23:51 <masonf> jarhar: I Don't think there are selectors that can do the same thing
15:24:01 <Lwarlow> Q+
15:24:17 <lea> q-
15:24:21 <astearns> ack masonf
15:24:29 <lea> q+
15:24:35 <masonf> masonf: you can't match exactly what :has-picker does with just a selector
15:24:45 <astearns> ack Lwarlow
15:25:12 <masonf> 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.
15:25:58 <masonf> lwarlow: I'm not sure we need to force browsers (from a spec perspective) to do something specific for appearance:auto
15:26:13 <masonf> q+
15:26:20 <masonf> q-
15:27:11 <masonf> 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
15:27:23 <masonf> lwarlow: each browser already has this, let's just expose it
15:27:27 <astearns> ack lea
15:27:51 <masonf> lea: can't easily do this with style selectors, but solution isn't an ad-hoc selector
15:27:51 <masonf> q+
15:27:54 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/24-css-minutes.html fantasai
15:28:06 <jarhar> q?
15:28:06 <masonf> lea: if we add a pseudo class, it needs to match appearance:auto
15:28:17 <Lwarlow> But that still doesn’t solve the issue (but yes we should have that)
15:28:24 <masonf> lea: I put a code snippet that shows circularity if you don't support appearance:auto
15:28:41 <masonf> lea: you said browser doesn't know if it showed a picker
15:28:45 <jarhar> q+
15:29:01 <masonf> lea: for author code, you know what you have generally. I don't know about use cases.
15:29:17 <masonf> lea: frameworks and libraries can have complex selectors
15:29:36 <astearns> ack masonf
15:29:47 <jarhar> masonf: the selector is pretty complicated, so frameworks and libraries are an actual use case
15:29:57 <lea> q+
15:29:58 <jarhar> masonf: its similar to ua stylesheets, its complicated enough that every browser has done it this way
15:30:04 <Lwarlow> It’s not even complicated it just isn’t possible…
15:30:05 <jarhar> masonf: it seems like the crux of this argument is
15:30:18 <jarhar> astearns: id like to see evidence that each browser does this
15:30:24 <jarhar> masonf: i think chromium and webkit have it
15:30:42 <lea> s/lea: for author code, you know what you have generally. I don't know about use cases./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./
15:30:47 <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
15:30:58 <jarhar> masonf: i think this comes down to naming or can it be done for everything
15:31:02 <lea> s/lea: frameworks and libraries can have complex selectors/lea: so I think the motivation is too weak to justify the complexity involved/
15:31:03 <jarhar> q-
15:31:17 <jarhar> masonf: can we return to the question of making it work for everything that has a picker?
15:31:20 <una> +1
15:31:27 <jarhar> masonf: its not possible for a browser to know whether it tried to open a picker
15:31:33 <jarhar> masonf: this might be a corner case
15:31:44 <Lwarlow> Q+
15:31:47 <jarhar> masonf: maybe we could just do :has-picker and make it work everywhere
15:31:59 <astearns> ack lea
15:32:08 <lea> The only reason it's complicated today is that we can't just `[size > 0], [multiple]`, which doesn't seem that complicated?
15:32:12 <masonf> lea: wanted to reply to the complex thing today. Reason is that we can't ... see comment
15:32:32 <masonf> lea: can't do attribute values today, but if we could, then
15:32:59 <lea> q?
15:33:08 <astearns> ack fantasai
15:33:16 <masonf> fantasai: I don't think we should go down the generic :has-picker thing
15:33:28 <masonf> fantasai: can we do that with pseudos
15:33:47 <lea> (that said making `:has()`work with pseudo-elements is also a common ask)
15:33:48 <masonf> fantasai: we don't have a generic use case here. Select is particular in that it has two forms.
15:33:57 <masonf> fantasai: let's do a specific select thing, therefore
15:34:21 <masonf> fantasai: I can imagine styling differently if the picker is shown, but that would be :picker-shown
15:34:26 <astearns> ack Lwarlow
15:34:40 <masonf> lwarlow: big +1 to that. Selector that just works for listbox vs. dropdown then that's great.
15:35:08 <masonf> 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
15:35:27 <masonf> lwarlow: :has-picker is doable, but :open isn't
15:35:43 <masonf> lwarlow: timing is tough, but whether you try to open a picker isn't
15:35:59 <masonf> lwarlow: :has-listbox is fine. Reason behind drop-down vs list-box isn't exposed in the platform
15:36:13 <lea> presumably `:listbox` , not `:has-listbox`?
15:36:14 <masonf> lwarlow: should be listbox rather than dropdown, because dropdown is too overloaded
15:36:25 <masonf> +1 from the scribe for something like that also
15:36:51 <masonf> annevk: I think for most other controls, you could use @supports with the picker pseudo element
15:37:05 <masonf> annevk: with select, there are two types of controls, only one with a picker. So select is indeed special.
15:37:06 <lea> q+
15:37:20 <masonf> annevk: you can tell if it supports it, but not whether it'll show one
15:37:42 <masonf> annevk: we haven't designed this part yet, maybe we should wait to define the rest first?
15:37:47 <lea> +1
15:38:34 <masonf> annevk: one concern I heard with listboxes more generally, including on desktop. On macos, there's no native ... multi-select dropdowns.
15:38:45 <masonf> annevk: That's a problem for trying to reconcile these things
15:38:49 <astearns> ack lea
15:39:26 <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.
15:39:28 <masonf> lea: for date pickers, it might be useful to render in the page.
15:39:33 <Lwarlow> Multiple dropdown basically is only a thing natively on iOS and android. So yeah that’s an issue
15:40:16 <lea> Lwarlow: What if it defaulted to appearance: base in platforms that don't support that? Since UAs have to implement that anyway
15:40:18 <masonf> 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.
15:40:39 <masonf> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12510
15:40:39 <github-bot> Topic: [css-forms-1] UA styles for base appearance listbox select elements
15:40:39 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12510.
15:40:51 <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.
15:41:01 <fantasai> in many form controls the picker is an optional aid, not the core part of the control
15:41:19 <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.
15:41:24 <lea> q+
15:41:31 <lea> q-
15:41:34 <masonf> jarhar: I think this is easy, compared to single-select, since it's just removing some things like button styles.
15:41:41 <Lwarlow> Yeah the embedded vs in page with optional picker is interesting
15:41:47 <lea> q+
15:42:00 <masonf> jarhar: I wrote a comment about 5 styles that should apply (commented on the issue).
15:42:09 <masonf> jarhar: overflow, border, display, and user-select
15:42:23 <masonf> jarhar: what do you think?
15:42:23 <astearns> ack lea
15:42:37 <una> q+
15:42:40 <masonf> lea: one requirement - it should be possible to size intrinsically to fit the contents.
15:42:48 <masonf> lea: seems like it should be possible, just don't want to lose track of this
15:43:07 <masonf> lea: once you can style them, you've got flexibility to change the appearance a lot. All of these require no scrolling.
15:43:19 <Lwarlow> Lwarlow has joined #css
15:43:28 <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.
15:43:38 <RobAtADP> RobAtADP has joined #CSS
15:43:40 <masonf> lea: if you say size:3 it doesn't do 3 lh's it says three options
15:43:50 <masonf> lea: however tall three options are. Not sure this is useful, but maybe.
15:43:58 <astearns> ack una
15:44:04 <Lwarlow> Q+
15:44:17 <masonf> una: generally these look good. I'm always a fan of simplicity. Fewer things for authors to override.
15:44:28 <masonf> una: I noticed padding block and inline that was removed. Why remove padding and gaps and things?
15:44:46 <masonf> jarhar: I think the padding and gaps are to space the content inside the button, so the picker icon has space.
15:45:01 <masonf> jarhar: and to make sure text inside the button is spaced away from edges. With listbox, that doesn't apply.
15:45:10 <lea> q+
15:45:14 <masonf> jarhar: option elements will already have those rules, and the options will fill the select.
15:45:22 <masonf> una: makes sense
15:45:24 <astearns> ack Lwarlow
15:46:00 <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.
15:46:16 <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.
15:46:26 <masonf> lwarlow: don't need to opt in to field-sizing: content
15:46:39 <masonf> lwarlow: only reason this isn't used more is that it isn't implemented everywhere
15:46:41 <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"/
15:46:56 <masonf> lwarlow: other than that, these styles make sense
15:47:05 <masonf> lwarlow: don't think it should have border or border radius
15:47:21 <masonf> lwarlow: just matching everything else makes sense. Should be box-sizing:border-box maybe?
15:47:31 <masonf> lwarlow: not having overflow:scroll is good. That's odd currently.
15:47:38 <astearns> ack lea
15:47:51 <masonf> lea: I agree with not having border radius, and generally the fewer styles the better.
15:48:09 <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.
15:48:32 <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?
15:48:47 <masonf> lea: agree that most authors want to set max height. Do we really need field-sizing, and !important?
15:49:21 <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
15:49:29 <lea> also just realized I was reading the select styles as listbox styles.
15:49:42 <masonf> lwarlow: question about form controls having special behavior in base appearance mode
15:49:50 <masonf> lwarlow: there's a CSS issue discussing this
15:50:13 <masonf> lwarlow: some people might like select's fixed behavior, automatically sizing based on longest option
15:50:33 <masonf> lea: I was reading the select styles, they do make sense for drop downselect, I just meant for listboxes
15:50:40 <lea> q+
15:50:43 <masonf> lwarlow: don't need the !important, that's likely an impl detail
15:51:26 <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.
15:51:41 <masonf> lea: we could also say field-sizing always resolves to content in appearance base or something
15:52:03 <masonf> lea: I was expecting flex, but you have inline-block. Authors can override.
15:52:22 <masonf> lea: do browsers use flex or something else?
15:52:46 <masonf> jarhar: picker with select is a flexbox, I'd imagine it's the same here for listbox right?
15:53:01 <masonf> jarhar: customizable-select picker is display:block
15:53:02 <Lwarlow> Q+
15:53:11 <astearns> ack lea
15:53:14 <astearns> ack Lwarlow
15:53:24 <ntim> ntim has joined #css
15:53:31 <masonf> lwarlow: we probably need a wider discussion of the display value in appearance:base.
15:53:40 <ntim> q+
15:53:42 <masonf> lwarlow: maybe it doesn't matter much here, but matters more in other controls
15:53:46 <lea> (also fewer things for authors to override)
15:53:54 <masonf> lwarlow: we should be consistent. Maybe select is special.
15:54:04 <astearns> ack ntim
15:54:13 <masonf> ntim: one goal for appearnace:base is to make it as close to a plain div as possible.
15:54:36 <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
15:54:44 <masonf> ntim: want to solve this generally
15:55:00 <masonf> ntim: maybe new field-sizing:auto value?
15:55:22 <masonf> astearns: want to reduce the number of author overrides, vs having it be close to a div. Those are in tension.
15:55:46 <masonf> astearns: need extra justification for things that make things more complicated for bare div
15:56:08 <masonf> ntim: from perspective of a new author, wondering why form controls behave differently. Try to fix with appearance:base
15:56:47 <masonf> astearns: we have these two sets of styles, but no way (yet) to decide between them
15:57:09 <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.
15:57:21 <masonf> s/swithc/switch
15:57:32 <masonf> astearns: we can move forward with these rules and have UA magic make them apply
15:57:54 <masonf> annevk: to be clear, I wasn't against exposing it, just wanted it to be consistent
15:58:03 <masonf> annevk: seems like some pseudo class is warranted.
15:58:56 <masonf> astearns: take this back to the issue, debate the things we didn't decide today
15:59:17 <masonf> topic:foo
16:00:24 <astearns> zakim, end meeting
16:00:24 <Zakim> As of this point the attendees have been lea, una
16:00:25 <Zakim> RRSAgent, please draft minutes v2
16:00:27 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/24-css-minutes.html Zakim
16:00:33 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
16:00:33 <Zakim> Zakim has left #css
16:33:53 <jamesn> jamesn has joined #css
16:58:35 <Adam_Page> Adam_Page has joined #css
17:04:49 <antonp> antonp has joined #css
18:02:08 <bkardell> bkardell has joined #css