Meeting 22 for joint OpenUI-WHATWG/HTML-CSSWG task force on styleable form controls

[josepharhar]

What is the issue with the HTML Standard?

The next meeting for the joint OpenUI-WHATWG/HTML-CSSWG task force on styleable form controls is scheduled for Thursday June 12th, 2025 at 8am PT.

[josepharhar]

I can give an update on customizable select with size and multiple attributes:

• UseCounter for users actually using the <select multiple> popup on mobile doesn't have a lot of data yet, but is now in stable chrome: https://chromestatus.com/metrics/feature/timeline/popularity/5549
• Planning on adding one button to close the picker for select multiple with popup based on this discussion: Should select multiple with popup have OK/Cancel buttons? openui/open-ui#1217
• Live demo?

[css-meeting-bot]

The CSS Working Group just discussed update on customizable select.

The full IRC log of that discussion

<dbaron> Topic: update on customizable select
<dbaron> github: https://github.com//issues/11367
<cwilso> jarhar: UseCounter for select multiple popup on android is currently at 0.0011, which seems pretty low to me; seems like a change I can make.
<cwilso> ... we had an openUI discussion about adding a button inside the picker; with select multiple that doesn't seem like a good behavior.
<cwilso> ...I've been prototyping adding a button to the picker, exposing as a pseudoelement so it can be styleable.
<keithamus3> q+
<cwilso> ack k
<cwilso> keithamus: I Think I missed that meeting around close button. user research found the most accessible thing was to have save and cancel buttons inside multi picker.
<cwilso> ...click to dismiss was deemed a bad idea for a11y. Just having an okay button was kind of awkward because you want to undo or not commit.
<cwilso> ... not sure how it will play out in real time.
<cwilso> ... most accessible way might be where cancel reverts.
<cwilso> ...I think it would be nice to give developers more extensibility, because if we choose one option and it's not the most accessible in the scenario, they might end up not using the select since they can't get the behavior they want.
<cwilso> ...Don't know if that's viable or not.
<cwilso> jarhar: makes a lot of sense. One thing worth mentioning, the ios multipler ticker has one close button with an X on it. when you tap on options it's live reflected into page state. Android has okay and cancel and does not reflect state until you commit.
<cwilso> ...there weren't a lot of super strong opinions in the discussion; having options for developer to choose sounds good. Might have to add an attribute or something.
<cwilso> keithamus: old behavior of click to dismiss would submit or commit. was frustrating for keyboard user, as they'd have gto go through all the clicks to un-highlight options to not commit changes.
<cwilso> ...the balance for making it accessible is you need an easier way for users of keyboard tech or assistive tech to easily undo. I still like the click to dismiss; obviously github is one example, but I think it's a good example. If GH woere to design their whole sidebar as a bunch of select panels, there would need to be fairly significant work. I think this extensibility is worth investigating.
<cwilso> ... if there's no customizability I think we might find developers end up rebuilding select.
<cwilso> jarhar: we could add attributes for all these things but not change the behavior.
<cwilso> ...based on what I've seen, a lot of demos people put their own buttons in but turn off the developments for check mark etc and put their own dom in anyway.
<cwilso> ... Mason suggested to me that we could have it live update, then every time the user toggles an option it could be an input event. then we can fire a. change event when they commit.
<cwilso> keithamus: fairly reasonable to have existing behavior; but if we're adding additional buttons it seems like customization is reasonable
<cwilso> ... maybe the answer is if you want any buttons you wrap the select element inyour own popever and you can have unlimited widgets around it.
<cwilso> jarhar: would be easier for us. but also in mobile versus desktop seems like a clear distinction.
<cwilso> ... so two ways to go: could encode everything in markup so we'd have attrs for what dismissal does, etc. Or we could go the other way just focus on in page listbox customizability, and let people build their own pickers suntil we try to figure that out.
<cwilso> keithamus: there are other things that would be interesting to add into pickers, like GH has typeahead. So a lot of extensions to select that websites build; may be demonstrating that attrs might not cover enough of the use cases, or that more markup is required.
<cwilso> jarhar: makes sense, good that we have popover and anchor positioning.
<cwilso> ... for now, I'll focus on the multiple in size problem and get cross platform issues done, and we can focus more generally on how to solve pickers more generally (or not)
<cwilso> cwilso: any other things to discuss?
<cwilso> keithamus: curious about required parser changes for customizable select?
<cwilso> annevk: hasn't changed for the last two months; jsut look at latest PR.
<cwilso> ... I think you'll have to do a separate PR for WPT
<cwilso> rrsagent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2025/06/12-css-minutes.html cwilso
<cwilso> rrsagent, make logs public
<RRSAgent> I have made the request, cwilso