– DRAFT –
customizable <select> breakout

jarhar: [introductions and link to https://docs.google.com/document/d/1MvNPO8E7TZtTK83WkLLyIY9k_m5T4-iCzfvXKzpEXhw/edit]
… combobox is what we shipped, working now on listbox
… can go through the basics if people want

[silence]

listboxes

github-bot: take up whatwg/html#11477

Base appearance for list box select elements

<github-bot> OK, I'll post this discussion to whatwg/html#11477.

jarhar: right now appearance: base-select doesn't work with the listbox select
… working on that
… another issue is a filterable combobox
… e.g. a dropdown with suggestions
… like in github
… pretty common pattern
… another big one was a select with a popup that's not an editable combobox
… so search through options like github's "labels"
… the in-page bit is just a button, but then there's a filter
… this is kinda similar to a combobox
… but different because you're forced to choose from a list of N values
… so working on an explainer with some overlap for these two use cases
… regarding autocomplete, looks like <input type=text> with datalist
… we could get a `<datalist>` with appearance: base
… also associating an `<input>` with a filterable select
… first we started trying to put an `<input>` inside `<select>`
… that needs more breaking parser changes
… also accessibility issues
… the input would need to be a direct child of the `<select>`
… so I think it'd be better if we allowed an `input` to be allowed with a `listbox` select
… authors can put that on a popup if needed
… [See Associating an input element with a select element in explainer]
… [in https://open-ui.org/components/combobox.explainer/]
… to make the github thing with the input and the select, you can have a popup with a dialog

JakeA: the size attribute I find weird
… we have height on CSS
… why?

jarhar: agreed, mostly a legacy thing
… we could add another attribute
… I proposed that a while ago
… we should learn more about why size doesn't work
… so kept going with size
… we could find another way to opt into listbox rendering
… there's another issue about how the height should be calculated

JakeA: yeah I guess we could also add size=any or so

jarhar: yeah that could work

sarah: I really like this approach rather than `<input>`-in-select
… but `<button>` with dialog, `<button>` doesn't support values
… I think there's another need for a button that has a value
… I don't think that's currently possible
… color / date pickers have picker and value

JakeA: buttons have a value

emilio: sarah, you mean in the form submission sense?

sarah: no, in the a11y sense

jarhar: I think figuring out how in this example you map the button as a combobox
… maybe since it has a select inside? but maybe another way to mark the button itself?

sarah: I think it could have a button (not combobox) role but have it a selected value
… windows is the only platform where they do combobox role for this
… I think it's more user understandable

jarhar: another idea is that dialog has a formulated semantics for submitting things
… so whatever dialog submits goes into the button or something

<masonf> emilio: I agree that it's better than having it inside select

<masonf> emilio: when you want to use it in a form, this forces you to have a hidden input where the value goes, right?

<sarah> form dialog?

jarhar: so the <input> shouldn't submit a value since it's only filtering the select

<masonf> emilio: the dialog would be inside the form, it'll be submitted (the select) and the button you don't do anything. Maybe it just works.

keithamus: I don't think there's any issue
… even with the input being submitted, without a name it won't submit
… even if it did it'd be trivial to discard

johanneswilm: In the initial example (the github tag filter)
… that had a lot more structure
… here the options are just one word
… could you implement that with this new structure?
… or do you need to resort to JS for more complex options?

jarhar: I don't think you'd need to resort to JS
… are you thinking about random elements in the <select>?

johanneswilm: yeah all the short description and color codes and so on

jarhar: if you're building that the <option> would have a `value` attribute that would be populated into the `<input>` but we have other APIs planned so you can implement your own filter

keithamus: we should be careful about using `value`
… the value might be the id of the database record or something
… the text content should probably be preferred
… or a new attribute
… even with supplementary descriptions
… it might not be bad to include those

jarhar: there's a tricky situation with how datalist works already
… when you choose an option the value attribute is what gets put into the input field

<sarah> an issue for providing the filterable text of options already exists for selects: openui/open-ui#1118

jarhar: there's also the `label` attribute that has other behavior
… that we'd have to clean up in some way

jarhar: in order to implement filtering
… if you have an editable combobox
… when you type letters they go into the textfield and arrows focus the <option>

<masonf> :focused-but-not-really-focused

jarhar: but typing still goes into the `<input>`
… so I think this could be model with a new pseudo-class
… I think it'd be a good way to model
… `:focused-option`

<masonf> emilio: its not really focused, it's more like active or selected

<masonf> emilio: tab navigation will move focus for real, right?

<masonf> emilio: you're typing, then you press Tab, that closes things right?

<masonf> jarhar: as I use the arrow keys, it populates the text field. Then pressing tab focuses the thing after.

<masonf> emilio: focus remains on the text box. So let's not call the pseudo class "focused" something.

<kbabbitt> +1 to calling the new pseudo something other than "focused"

<masonf> JakeA: is it actually populating the text field live?

<masonf> emilio: don't we have a :selected pseudo for selected options?

keithamus: yeah in this one arrows are committing the option

kbabbitt: yeah but :selected isn't quite that

keithamus: how do you distinguish multiple selected options v.s. the active one

sarah: yeah I'd lean towards :active of sorts
… you might want to keep those separate

<kbabbitt> +1 sarah

<masonf> emilio: the github example has multiple things that don't match the active state, since it's multi-select

<masonf> emilio: naming is tough

JakeA: the urlbar in Firefox does the same as wikipedia, chrome has escape but also selects the first option
… google.com has the escape and doesn't do the first option thing

sarah: I did a bunch of research on these keyboard
… I think people expect tab to commit, but esc to not commit
… some people do expect esc to commit

<masonf> emilio: tab committing I'd expect if I moved around in the list, but if I didn't, that would feel weird

sarah: depends on whether the combobox enforces a value or is free-form

emilio: but I'd expect to clear or commit the firs then, and then move me to the next value

<jarhar> openui/open-ui#1319

jarhar: there's an openui issue about supporting a lot of these out of the box or not

frehner: when you are using up/down, just for clarity, is this spacebar a text input or selection of something?

jarhar: for the editable combobox you'd type space

sarah: some comboboxes expect expect to select, depending on context
… sometimes they strongly expect them to select
… there's a strong user expectations one way or the other

JakeA: yeah in email, comma might commit the selection

keithamus: Yeah we probably should make every visible character populate the input, and if you need custom behavior you use script

adamargyle: is <input type=search> relevant here?
… what's the delta between filtering vs searching here
… mostly interested in the clear button
… which search input comes with a clear feature

jarhar: I think you could use search interchangeably
… I don't think there's semantic differences

emilio (and keithamus): If you press escape it clears

keithamus: Ideally it should just worth with search input

<masonf> emilio: similar to what Keith said. We should pick reasonable keyboard semantics.

<masonf> emilio: we shouldn't support all the complicated use cases out of the box

masonf: for a good reason, if there's no natural choice then JS is the way out

sarah: there's a switch about whether affects free-form input or not, space selects, if not people lean expect space to select, there are a bunch of other behaviors

keithamus: the other thing showing the option that would be committed if it's not free-form
… whenever there's a default selected applying that in placeholder style

<masonf> emilio: there's no way to say this input will take one of the options. It's free form always

<masonf> keithamus: that's a bit lift. Richer text inputs that include this feature.

jarhar: definitely editable combobox is free form text
… you could build on top of it to make it behave like you want

sarah: we could say that if you're not using freeform you should use <input> inside <dialog> which is more accessible

<keithamus> https://open-ui.org/components/richer-text-fields.explainer/

sarah: ghost text is wildly inaccessible and messes up screen readers nowadays
… browsers could do it right

keithamus: I think a ghost text pseudo of sorts could be useful

<masonf> emilio: if you wanted to build it yourself, can't you do that with custom highlighting?

<masonf> emilio: it'd become part of the value, and the insertion point is hard, but you could do it that way?

<masonf> sarah: that might also screw up the a11y

<masonf> emilio: does the screen reader - once the value changes that's a problem.

<masonf> keithamus: need additional announcement for when ghost text gets populated

<masonf> keithamus: "you just typed this, we'll autocomplete that"

<masonf> sarah: backspace will delete highlighted, you want to delete the ghost text

<masonf> emilio: keep ghost text as part of the value, but style the ghost part differently

<masonf> sarah: move the insertion point - that breaks if it's part of the value

<masonf> emilio: move cursor to end would commit the value. It's tricky. Seems like a can of worms

jarhar: re. filtering
… one million options, and making it usable is tricky

<masonf> that's literally 1 million by the way

jarhar: other use cases are like autocomplete and fetch some of the options
… what I have right now is you have some filtering out of the box when you do either of these things
… for datalist it already does the filtering for you
… we could make this work with a `:filtered` pseudo-class of sorts which would make it display: none
… also some ideas about adding attrs with different values like pattern / startswith / complete
… for more interesting cases for custom filtering or dynamic options
… we have the beforefilter event
… so before the filter it'll fire the event on something and you can preventDefault it and some mechanism to repopulate the entire list box and do something to tell the browser that you're done doing the filtering
… and some way of designate options as filtering

keithamus: curious about `pattern`, but one thing about `search` we ran in github
… is people not knowing why a particular option matched the filter
… e.g. options in the branch picker, it uses fuzzy-finding
… every character that matches is made bold
… we could use highlights to do that
… but that doesn't support boldness

adamargyle: font variations can use it

<masonf> emilio: including a way to do your own filtering seems important. Do it yourself

<masonf> emilio: wouldn't be too hard to make something easy to do

<masonf> emilio: you can build the matching thing, but it might be more common... in the firefox settings, there is fuzzy matching, not even part of the word. Cookies might find site data settings.

<masonf> emilio: start simple, then add later

masonf: +1, I don't like the search attribute at all, it should be basic basic search
… and js for the rest

<masonf> emilio: expose a good way to implement filtering yourself then we can build more later.

<adamargyle> using grad to prevent CLS but making letters appear bolder https://web.dev/blog/more-variable-font-options-in-chromium-83#grad

keithamus: the branch and file pickers are prefetch. The file picker is debounced and performs a debounced sort
… user search performs a debounced search
… most of the perf cost is moving options in the dom, maybe improvable

jarhar: Yeah also in favor of getting rid of the search attribute
… kept it because it was in the original combobox explainer

keithamus: the default should be then...

emilio: substring or startsWith?

masonf: one of those?

johanneswilm: yeah what are you supposed to do in JS?
… it should be async
… what do I get handed

keithamus: beforefilter gets you an opportunity to preventDefault()

johanneswilm: how am I supposed to apply a `:filtered` pseudo-class?

masonf: not sure yet, we need some ideas

emilio: I'd do the simple thing of having a boolean HTMLOptionElement.filtered

<jarhar> here is the issue about how to do this: openui/open-ui#931

<masonf> emilio: there's a way to match stuff - you may get new options to add, etc. Just something basic, if you want to add options, ok. Do whatever you need in the event listener.

<masonf> emilio: we could also just say that if you preventDefault, you're on your own

<masonf> emilio: not worth it to provide a complex API

keithamus: maybe this comes with the prototype but if you don't inform the browser it's done, what does it show?

<masonf> emilio: if you're doing your own filtering, then you can show a spinner or fade the list or whatever you like

<masonf> emilio: disable the browser filtering, do your own thing.

<masonf> jarhar: ok I agree

jarhar: I have some example scripts that I wrote
… I'd love to see if anyone has code examples about how this should work

sarah: some things to consider
… defining some "no options matched" text
… without having to take over filtering
… something similar to what emilio said, you have United Kingdom but also match britain or so
… you don't want that in your filtering logic
… and use that would be very useful

keithamus: if it was using textContent you could use `<span style="display: none">`

sarah: that doesn't quite work because you want them to be exclusive

johanneswilm: could be like a data table where some columns are displayed and not

<johanneswilm> and some are searchable and others are not. searchabe doesn't always match displayed

keithamus: an attribute on an option could be...
… but what happens if you put garbage on it?

sarah: yeah I hadn't thought about attack vectors

jarhar: similar to typeahead for select

frehner: yeah if browser default is startswith it can get a bit hairy

keithamus: or should it be includes

kbabbitt: I agree we need some extensibility
… but if there's a very small scoped options like startswith and so on that'd be good

<frehner> emilio: when you have a country list I would prefer includes/contains

keithamus: I live in "the united kingdom" where it can be frustrating

adam: Was testing the keyboard behavior of select, I noticed there's a delta where combobox. Teaching users many different ways to do something similar seems bad. In customizable select it moves through the options

<kbabbitt> our engineers working on webui are very interested in eliminating as much JS as possible, if we can provide a scoped list of widely-used built-in searches such as startswith vs includes, or whole-word vs partial-word, I think that would be good

jarhar: that looks like a bug

adam: Maybe just because I arrowed then tab

jarhar: when option receives a tab key down it should select

adam: Spacebar is also making choices
… current select element allows spacebar to make the choice

adam: also <select> down arrow pops the picker sometimes, but would be good to figure out those details

<frehner> emilio: this also depends on each OS/env, so there's variance here

<frehner> ... I would prefer to come up with something consistent here

jarhar: in chrome I'd probably make it consistent across platforms
… but the spec probably needs to be optional (same for wpt)

sarah: Some of this behavior is unintuitive for users