select: provide a way for authors to define the string value of rich options

[smhigley]

Introducing the ability to render structured rich content within options also introduces the need for authors to be able to separately define the rendered DOM in the option vs. the string-typed text used for features like typeahead / type-to-navigate.

I ran into this exact issue while creating the Dropdown & Combobox controls in the library I work on. A concrete example can be found in UI like this:

When displaying the selected value in the trigger button we only want to display the text of the person's name. This is currently possible using <selectedoption> + custom CSS display: none styles. What isn't currently possible is enabling users to type e.g "Elv" to jump to "Elvia Atkins", Or repeatedly typing the same letter to cycle through multiple people whose names all start with that letter.

The best we can do as a browser fallback is to use the text content of the entire option, which is not always conceptually the text that a user would try to type. That still seems fine to me as a default, but authors who want to do the right thing currently have no ability to customize this.

The other potential reason for needing this is if we keep the same <option> model & attributes in a future editable select, there will need to be a way to define what string-only value gets inserted into the <input> when an option is selected.

Solutions

There are a couple current HTML attributes on the option element that are at least conceptually similar to this idea:

• label: right now this overrides the displayed text of the <option> if defined. Repurposing this to no longer override the text could be considered breaking (maybe?), although otherwise this feels like a good fit.
• value: even though the word "value" captures the idea of this feature, repurposing current behavior of value -- which is the form-submitted non-human-readable value -- would be a bigger and more breaking change.

The other option (heh) is to create a new HTML attribute specifically for the string version of option's primary text. This is what we do in my library, using text. For example, the options in the above screenshot have roughly this code:

<Option text="Elvia Atkins" value="eatkins">
  <Avatar />
  Elvia Atkins
  <span class="status">Busy</span>
</Option>

Open questions:

• Assuming we add or repurpose an attribute for this, should that attribute ever be used as the displayed text in the select trigger?
• Should it ever be used in the calculation of the accessible value string? (which should probably match the displayed text most of the time)

Related: #1117

[josepharhar]

label: right now this overrides the displayed text of the <option> if defined. Repurposing this to no longer override the text could be considered breaking (maybe?), although otherwise this feels like a good fit.

I agree it feels like a good fit, but going through with it is probably going to be complicated. The current behavior is very unfortunate. Hopefully we can just stop rendering the label attribute for the new mode: https://github.com/openui/open-ui/issues/1115

value: even though the word "value" captures the idea of this feature, repurposing current behavior of value -- which is the form-submitted non-human-readable value -- would be a bigger and more breaking change.

Yeah I'm not sure the value attribute should be used for typeahead or anything thats exposed to the user at all.

Assuming we add or repurpose an attribute for this, should that attribute ever be used as the displayed text in the select trigger?

It sounds like ideally we would not use the label attribute when rendering anything so that it could be used for this use case.

Should it ever be used in the calculation of the accessible value string? (which should probably match the displayed text most of the time)

Great question!

[josepharhar]

I think we still need to figure out how we are going to incorproate the option label attribute for accessibility mappings, but

Proposed resolution: Use the option's label attribute for typeahead. If there is no label attribute, then use the option's text content for typeahead.

[josepharhar]

The tone about standardizing keyboard behavior makes me believe that getting interoperable typeahead isn't going to be possible: https://github.com/openui/open-ui/issues/1087

I think this means that we can't add a new attribute for typeahead, but I'm happy to implement whatever typeahead behavior you think is best in chromium.

[css-meeting-bot]

The Open UI Community Group just discussed select: provide a way for authors to define the string value of rich options.

The full IRC log of that discussion

<gregwhitworth> sarah: this is largely about being able to do type-ahead and you open a list of states and type in WA for Washington or similar
<gregwhitworth> sarah: it will jump you to that option and the issue here is that with rich content the text content of the option is not going to get you the most valuable
<gregwhitworth> sarah: a better example is emails, where it's their role/title, name, status but ultimately the type ahead wants to search for name
<gregwhitworth> q+
<masonf> q+
<gregwhitworth> https://open-ui.org/components/combobox.explainer/#introducing-search-attribute
<jarhar> gregwhitworth: i did not read this
<jarhar> gregwhitworth: we introduced this proposal for combobox, which is the search attribute for this problem
<jarhar> gregwhitworth: we were thinking about the same thing. should you be searching the email or the values or all of the contnet
<jarhar> gregwhitworth: basically what we wanted to do was - we introduced some basic things that programatic languages are used to. we would then bring in pattern to search. heres how i wanted to search these things
<brecht_dr> q+
<jarhar> gregwhitworth: on top of that prior to this we also had the filter
<jarhar> gregwhitworth: heres how youre going to search. are you wanting to remove them or jump to them?
<jarhar> gregwhitworth: just wanted to share those thinkings that we had
<gregwhitworth> ack gregwhitworth
<sarah> q+
<jarhar> q+
<jarhar> masonf: im glad you went first
<gregwhitworth> masonf: I'm glad you went first
<gregwhitworth> masonf: the attribute on each option I see it being a foot gun and changing the actual content vs the attribute
<gregwhitworth> masonf: you may not notice that it's broken
<gregwhitworth> masonf: if it's the attribute on the select
<gregwhitworth> ack masonf
<gregwhitworth> ack brecht_dr
<gregwhitworth> brecht_dr: I had same concern that masonf had and that people could do malicious things
<gregwhitworth> brecht_dr: I was thinking that I understand why we want this but I also have this feeling we can do this with CSS so that the typing will work on the first item inside of the DOM
<gregwhitworth> brecht_dr: I don't see a large benefit in this usecase
<gregwhitworth> brecht_dr: you'll have to fix this in styles alone and not layout
<gregwhitworth> q+
<gregwhitworth> ack sarah
<gregwhitworth> sarah: going to that first, having to re-arrange with CSS and visual vs dom order has a11y issues
<masonf> reading-order FTW?
<gregwhitworth> sarah: then you create a conflict between good keyboard and good AT issues
<gregwhitworth> brecht_dr: I do know the CSS WG is working on reading-order?
<gregwhitworth> sarah: would the type-ahead be different
<gregwhitworth> sarah: also, having this weird gotcha that your visual markup will impact it seems weird to me
<gregwhitworth> sarah: the reason it is a bit more complex is that it is more complex than combobox search
<gregwhitworth> sarah: maybe you want the filter-ing string to catch names within certain values, etc
<gregwhitworth> sarah: it can be really valuable
<gregwhitworth> sarah: for this behavior and you touch one letter multiple times it filters through them
<masonf> q+
<gregwhitworth> sarah: when you're typing a longer string
<gregwhitworth> sarah: this gets a little more complex
<gregwhitworth> ack jarhar
<gregwhitworth> jarhar: I wanted to say a new attribute it may be hard to spec and they have this thing called typeahead and they can use how this works vs doesn't
<brecht_dr> q+
<gregwhitworth> jarhar: given the existing attributes in content
<gregwhitworth> jarhar: if you want it to run a certain way you can try and implement it that way
<gregwhitworth> sarah: when you say go implement that do you mean the browser author or dev?
<jarhar> i got it
<jarhar> gregwhitworth: +1 to what you said sarah
<jarhar> gregwhitworth: theres a can of worms to unpack with the search existing on select
<jarhar> gregwhitworth: i want this aspect of this content to have a key for quick searching
<jarhar> gregwhitworth: i think thats what youre rasiing which is like xml style content to identify for searching
<jarhar> gregwhitworth: and then theres the orthogonal part which is hitting the same characters and different characters. thats getting into we need a filter
<jarhar> gregwhitworth: its the behavior that happens when youre typing. whehter it jumps or whether it does this
<sarah> q+
<jarhar> gregwhitworth: as you reason about that content what should the behavior take on? does it jump or filter? selects today jump
<jarhar> gregwhitworth: i dont think i want to get too in the weeds too quickly with having numerous things on the options
<jarhar> gregwhitworth: you could search the value or the pattern of the text content within
<jarhar> gregwhitworth: we could explore numerous. i dont think theres any one right path
<gregwhitworth> ack gregwhitworth
<jarhar> gregwhitworth: everything youre bringing up is valid
<gregwhitworth> ack masonf
<jarhar> masonf: we should remember that this isn't specced behavior at all right now.
<gregwhitworth> masonf: this isn't specified behavior right now and I do want to do something about making type-ahead better and one of them is how do you determine what to search
<gregwhitworth> masonf: determine what's in the buffer
<gregwhitworth> masonf: I've seen some good selects is it not only shown but it filters them
<gregwhitworth> masonf: it does require specifications and standards and it's a long way to say to keep talking about this but not making it a part of V1
<gregwhitworth> masonf: try later to ship an attribute but how to bind it with behaviors that are common
<gregwhitworth> q?
<gregwhitworth> ack brecht_dr
<gregwhitworth> brecht_dr: I'm with the idea to get more user data to come to a conclusion and the other way around is to specify what you don't want to be included in the search
<gregwhitworth> brecht_dr: that may be a more prominent usecase
<gregwhitworth> brecht_dr: it may sort of a reference like the selectedcontent element and have the items to be read while you're typing
<gregwhitworth> brecht_dr: I do see some different options on how this could go
<gregwhitworth> sarah: I do like having selectors determining what is the correct one
<gregwhitworth> sarah: I remember the other usecase for this is there an editable version determining what text appears in the input field as it can only take text
<gregwhitworth> sarah: you need the text that is inserted vs value to be defined
<gregwhitworth> sarah: the search wouldn't work for that
<gregwhitworth> sarah: the more that you look at this it could cover the proposal
<gregwhitworth> sarah: on user data, we implemented this in our custom select so I'm very familiar with this
<gregwhitworth> sarah: the search algo is different vs editable and non-editable
<gregwhitworth> sarah: the timing of how you type determines if it's a different word or the same word, such as aardvark
<gregwhitworth> sarah: you can keep typing the same letter without timing you'll have issues and show/hide things on a timer
<gregwhitworth> q+
<gregwhitworth> ack sarah
<gregwhitworth> sarah: the tricky thing with user data are not asking people that use it vs the people building
<jarhar> i got it
<jarhar> gregwhitworth: it feels like we want to - should we pull out the search attribute and call it typeahead or whatever as its own individual doc thing?
<jarhar> gregwhitworth: so its not tied to combobox since were talking about it for select and combobox - so like this should just apply to datalist as well
<jarhar> gregwhitworth: the other thing, my gut instinct is that youre bringing up the editable one. are you referring to i can add new options in response to typing?
<jarhar> sarah: ive avoided making a difference between select and combobox because select is a combobox
<jarhar> gregwhitworth: all i was going to say was my gut instinct is that once we land combobox thats what everybody will use in 90% of use cases
<jarhar> sarah: theres a difference between needing something you type in and not type in
<jarhar> gregwhitworth: i heard two thing: attribute typeahead solution should be incubated. the other is the v1 of select for this.
<jarhar> gregwhitworth: is there anything else i missed?
<jarhar> sarah: i think my question is do we want to use the same thing here - do other people - if we need an attribute anyway for combobox, datalist, whatever, for the putting the desired text content in the input. if we dont need it then i think the typeahead search thing is a good approach too
<jarhar> gregwhitworth: are you saying that we need to have this for select v1?
<jarhar> sarah: i dont want to underestimmate how much people do thsi because i think people do this a lot
<brecht_dr> q+
<jarhar> gregwhitworth: so thats the default. what exists today thats not specified is the default. whatever new attribue we bring in that would be the default.
<jarhar> gregwhitworth: then we'll end up being like heres how we want you to iterate on top of x
<jarhar> gregwhitworth: to masons point, heres where the behavioral filters can come in or not
<gregwhitworth> sarah: my worry is to separate the behavior and what text it's using and the text that it matches is more complex
<jarhar> sarah: my worry is that i want to seaprate the behaivor which is go from the start and what text its using and the new thing about the new select is the text is using doesn't necessarily matc the text you want to use becuase of the way that you can make options more complex
<jarhar> sarah: for comparison, when i was working on the combobox and dropdwon in my library, we needed this at the start because of how people style options. the text content was not what you wanted to use for this behavior
<jarhar> masonf: ive been treating this as a v2 thing because it will mostly work and there were corner cases. are you syaing they're not corenr cases?
<gregwhitworth> q?
<gregwhitworth> ack gregwhitworth
<jarhar> sarah: yeah theres options with big text in the middle and an option with some text above and below
<jarhar> masonf: so the alt text wouldnt count but the big text and subtext would count
<jarhar> masonf: so how often do people build things like that and that would help us prioritze fixing it
<gregwhitworth> q+
<jarhar> sarah: i dont know if i want to say this should block it. consider it as important, but i agree its good to see how people use this
<gregwhitworth> ack brecht_dr
<jarhar> brecht_dr: i understand these concerns. on the other hand whats been said here before is that we started with something called customizable select which has the same behavior thats only customizable and we're trying to create a swiss army knife out of it. maybe the idea of not blocking v1 is good because its just a select that you can style as your
<jarhar> own hands. as you search for something its just the first string you find inside the option
<masonf> q+
<jarhar> brecht_dr: for v1 its still a select, but this is an important issue we should think about. i dont think this is blocking for the idea of a customizable select being shipped. it doesn't have to be a swiss army knife from the start
<sarah> q+
<jarhar> gregwhitworth: i feel like you summed up what i would say sarah, which is one thing i want to stress is that v1 and v2 - the v2 does not have to take the same amount of time as v1. v1 we've laid so much groundwork and done so much standardization. i dont watn the premise of that to mean that its going to wait 5 years
<jarhar> gregwhitworth: we could be landing pattern 6 months later
<jarhar> gregwhitworth: this group could be riffing more on your specific scenario
<jarhar> gregwhitworth: you can quickly just start being iterative because that foundation is there
<jarhar> gregwhitworth: we're not going to tackle this in a waterfall manner. i agree this is important. people are going to put email, and people are typing one thing and seeing another
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack masonf
<gregwhitworth> masonf: +1 to what gregwhitworth said and I do see this
<jarhar> masonf: +1 to what greg said actually. the same thing happened with popover and anchor positioning. it took a while to fix the first thing, but we've been able to incrementally ship new stuff for those features.
<gregwhitworth> masonf: it took a while to ship the first thing and then we'll be able to quickly incrementally ship features
<gregwhitworth> scribenick: jarhar
<jarhar> masonf: something brecht said - since we are reusing the select element it has this nice thing where it progressively enhancnes. it might be a good thing if the typeahead behavior is the same. if the dev in sarahs exmaple - if that is not progressively enhanced, the old select would still be searching for the same text, they will get the same thing
<jarhar> in the old select or new
<gregwhitworth> q?
<gregwhitworth> ack sarah
<jarhar> sarah: for things that come after v1, you can just ship a singular feature on its own? awesome! i think i agree
<jarhar> gregwhitworth: think of csswg, they had css 1 and 2 and 3. this is just getting customizable select out the door
<brecht_dr> q+
<jarhar> sarah: if you have something thats easy to get through standards it could be a 3 month fast follow
<jarhar> masonf: it needs to be backwards compatible and enhance
<gregwhitworth> ack brecht_dr
<jarhar> brecht_dr: just to respond to mason, i think thats a big benefit. if its backwards compatible and behaves the same,
<jarhar> brecht_dr: that makes it a bit more easy for developers to understand that im going for modern browsers rather than backwards compatible
<jarhar> gregwhitworth: sarah since yo uopeened this are you lookking for a resolution?
<jarhar> sarah: greg would you be open to working with me outside of this? i would like to get a solution quickly. swiss army knife analogy, i would think of this more like a blade lock rather than an additional feature just to make the new stuff more safe
<jarhar> gregwhitworth: i can bring in the person who helped write that from internal meetings. we can spread it across 3 people
<jarhar> masonf: i think it would be great to pull it out in a separate explainer
<jarhar> gregwhitworth: the second they introduced the search thing, calling that attribute search is actually confusing
<jarhar> gregwhitworth: ill go ahead and do that i dont think we need a proposed resolution
<gregwhitworth> Zakim, end meeting