– DRAFT –
Open UI

github-bot, take up openui/open-ui#1127

select: use cases for opening the picker without user activation

<github-bot> OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1127.

masonf: the question is a link to the WHATWG question

masonf: there is this thing called showPicker() that works for select, etc

masonf: in all of those scenarios they open a separate window and they REQUIRE user activation since it's in a new window. In customizable select it is not a new window and so it is not a privelaged window

masonf: should it be allowed to be triggered without user activation

masonf: there aren't any real concerns from a security perspective but is there a usecase for this? The only clear one is that it's for testing

brecht_dr: I'm feeling strongly towards needing it rather than an opinion on this with something like invokers

brecht_dr: you could open it?

masonf: what do we do with invokers, we do click which are user activation

masonf: I don't think it works right now if you have an invoker and point it to select and programatically have it invoke the click

masonf: targeting a select is a new capability for an invoker

brecht_dr: I wanted to ask the question alongside it. Could this impact that behavior in some way. I'm not opposed to having not having this but I do like the idea of invokers and using it for select

masonf: I see, I don't see why the commandfor shouldn't be able to point to a select and that open the select

masonf: and that is the user activation

masonf: I don't think we NEED a resolution for this

<jarhar> gregwhitworth: so this is a noop api now?

<jarhar> masonf: if you call showpicker with no activation, it throws an exception right now.

<jarhar> gregwhitworth: i like having the artifact that we are resolving to keep the behavior as is

<jarhar> gregwhitworth: but we intentionally made the decision not to change the behavior

<jarhar> masonf: i was hoping for the opposite resolution

<jarhar> gregwhitworth: im not opposed to it either, but i dont see a strong reason to change the html spec

<jarhar> gregwhitworth: the irony is the scenarios that popped into my head: the dropdown is opened by default, but that is occurring due to focus being forced into that thing

<jarhar> masonf: that was something from westbrook, which was having it open by default on page load. that would not be possible without this

<jarhar> gregwhitworth: i can't recall. when we focus in on the select does it happen or is it with the keyboard?

<jarhar> masonf: keyboard

<jarhar> gregwhitworth: ok yeah. there are use cases where it forces you into a pick list by default

<jarhar> gregwhitworth: so when this thing gets focused i would show that popup

<jarhar> gregwhitworth: i cant remember where i encountered this in salesforce

<jarhar> gregwhitworth: when we were talking about open forever, people were saying we want defaultopen, but people can programatically do it

<jarhar> masonf: defaultopen was a declarative way to do something you can do with script. but this is different because you can't do it in script at all

<jarhar> gregwhitworth: this would become a web compat concern since its throwing exceptions

sarah: the caveat is that the usecases are on editable comboboxes with open on focus

sarah: there are things where we want to keep them open all the time while you're typing

sarah: the other is when you have teaching UI and you have a thing that we open programmatically

<dbaron> +1 to the teaching UI case (which I was thinking about mentioning)

masonf: I have two examples from this discussion which is opening on load and teaching UI where it opens the select

Proposed Resolution: There are real world usecases for opening a picker using require programmatic activation on a custom select

<masonf> +1

Proposed Resolution: There are real world usecases for opening a picker using programmatic activation on a custom select

<brecht_dr> +1

RESOLUTION: There are real world usecases for opening a picker using programmatic activation on a custom select

<sarah> +1

github-bot, take up openui/open-ui#1118

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

<github-bot> OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1118.

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

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

sarah: a better example is emails, where it's their role/title, name, status but ultimately the type ahead wants to search for name

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

<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

<jarhar> masonf: im glad you went first

masonf: I'm glad you went first

masonf: the attribute on each option I see it being a foot gun and changing the actual content vs the attribute

masonf: you may not notice that it's broken

masonf: if it's the attribute on the select

brecht_dr: I had same concern that masonf had and that people could do malicious things

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

brecht_dr: I don't see a large benefit in this usecase

brecht_dr: you'll have to fix this in styles alone and not layout

sarah: going to that first, having to re-arrange with CSS and visual vs dom order has a11y issues

<masonf> reading-order FTW?

sarah: then you create a conflict between good keyboard and good AT issues

brecht_dr: I do know the CSS WG is working on reading-order?

sarah: would the type-ahead be different

sarah: also, having this weird gotcha that your visual markup will impact it seems weird to me

sarah: the reason it is a bit more complex is that it is more complex than combobox search

sarah: maybe you want the filter-ing string to catch names within certain values, etc

sarah: it can be really valuable

sarah: for this behavior and you touch one letter multiple times it filters through them

sarah: when you're typing a longer string

sarah: this gets a little more complex

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

jarhar: given the existing attributes in content

jarhar: if you want it to run a certain way you can try and implement it that way

sarah: when you say go implement that do you mean the browser author or dev?

gregwhitworth: +1 to what you said sarah

gregwhitworth: theres a can of worms to unpack with the search existing on select

gregwhitworth: i want this aspect of this content to have a key for quick searching

gregwhitworth: i think thats what youre rasiing which is like xml style content to identify for searching

gregwhitworth: and then theres the orthogonal part which is hitting the same characters and different characters. thats getting into we need a filter

gregwhitworth: its the behavior that happens when youre typing. whehter it jumps or whether it does this

gregwhitworth: as you reason about that content what should the behavior take on? does it jump or filter? selects today jump

gregwhitworth: i dont think i want to get too in the weeds too quickly with having numerous things on the options

gregwhitworth: you could search the value or the pattern of the text content within

gregwhitworth: we could explore numerous. i dont think theres any one right path

gregwhitworth: everything youre bringing up is valid

masonf: we should remember that this isn't specced behavior at all right now.

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

masonf: determine what's in the buffer

masonf: I've seen some good selects is it not only shown but it filters them

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

masonf: try later to ship an attribute but how to bind it with behaviors that are common

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

brecht_dr: that may be a more prominent usecase

brecht_dr: it may sort of a reference like the selectedcontent element and have the items to be read while you're typing

brecht_dr: I do see some different options on how this could go

sarah: I do like having selectors determining what is the correct one

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

sarah: you need the text that is inserted vs value to be defined

sarah: the search wouldn't work for that

sarah: the more that you look at this it could cover the proposal

sarah: on user data, we implemented this in our custom select so I'm very familiar with this

sarah: the search algo is different vs editable and non-editable

sarah: the timing of how you type determines if it's a different word or the same word, such as aardvark

sarah: you can keep typing the same letter without timing you'll have issues and show/hide things on a timer

sarah: the tricky thing with user data are not asking people that use it vs the people building

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?

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

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?

sarah: ive avoided making a difference between select and combobox because select is a combobox

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

sarah: theres a difference between needing something you type in and not type in

gregwhitworth: i heard two thing: attribute typeahead solution should be incubated. the other is the v1 of select for this.

gregwhitworth: is there anything else i missed?

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

gregwhitworth: are you saying that we need to have this for select v1?

sarah: i dont want to underestimmate how much people do thsi because i think people do this a lot

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.

gregwhitworth: then we'll end up being like heres how we want you to iterate on top of x

gregwhitworth: to masons point, heres where the behavioral filters can come in or not

sarah: my worry is to separate the behavior and what text it's using and the text that it matches is more complex

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

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

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?

sarah: yeah theres options with big text in the middle and an option with some text above and below

masonf: so the alt text wouldnt count but the big text and subtext would count

masonf: so how often do people build things like that and that would help us prioritze fixing it

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

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

own hands. as you search for something its just the first string you find inside the option

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

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

gregwhitworth: we could be landing pattern 6 months later

gregwhitworth: this group could be riffing more on your specific scenario

gregwhitworth: you can quickly just start being iterative because that foundation is there

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

masonf: +1 to what gregwhitworth said and I do see this

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.

masonf: it took a while to ship the first thing and then we'll be able to quickly incrementally ship features

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

in the old select or new

sarah: for things that come after v1, you can just ship a singular feature on its own? awesome! i think i agree

gregwhitworth: think of csswg, they had css 1 and 2 and 3. this is just getting customizable select out the door

sarah: if you have something thats easy to get through standards it could be a 3 month fast follow

masonf: it needs to be backwards compatible and enhance

brecht_dr: just to respond to mason, i think thats a big benefit. if its backwards compatible and behaves the same,

brecht_dr: that makes it a bit more easy for developers to understand that im going for modern browsers rather than backwards compatible

gregwhitworth: sarah since yo uopeened this are you lookking for a resolution?

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

gregwhitworth: i can bring in the person who helped write that from internal meetings. we can spread it across 3 people

masonf: i think it would be great to pull it out in a separate explainer

gregwhitworth: the second they introduced the search thing, calling that attribute search is actually confusing

gregwhitworth: ill go ahead and do that i dont think we need a proposed resolution