18:35:44 <RRSAgent> RRSAgent has joined #openui
18:35:48 <RRSAgent> logging to https://www.w3.org/2024/11/14-openui-irc
18:56:18 <brecht_dr> brecht_dr has joined #openui
19:00:35 <gregwhitworth> Zakim, start meeting
19:00:35 <Zakim> RRSAgent, make logs Public
19:00:36 <Zakim> please title this meeting ("meeting: ..."), gregwhitworth
19:01:32 <masonf> masonf has joined #openui
19:01:39 <gregwhitworth> meeting: Open UI
19:01:44 <gregwhitworth> chair: Greg Whitworth
19:03:02 <jarhar> jarhar has joined #openui
19:04:47 <sarah> sarah has joined #openui
19:04:55 <gregwhitworth> scribenick: gregwhitworth
19:05:00 <gregwhitworth> github-bot, take up https://github.com/openui/open-ui/issues/1127
19:05:00 <github-bot> Topic: select: use cases for opening the picker without user activation
19:05:00 <github-bot> OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1127.
19:05:15 <brecht_dr> present+
19:05:27 <gregwhitworth> masonf: the question is a link to the WHATWG question
19:05:38 <gregwhitworth> masonf: there is this thing called showPicker() that works for select, etc
19:06:22 <gregwhitworth> 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
19:06:38 <gregwhitworth> masonf: should it be allowed to be triggered without user activation
19:07:04 <gregwhitworth> 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
19:07:05 <brecht_dr> q+
19:07:10 <gregwhitworth> ack brecht_dr
19:07:30 <gregwhitworth> brecht_dr: I'm feeling strongly towards needing it rather than an opinion on this with something like invokers
19:07:31 <gregwhitworth> q+
19:07:43 <dbaron> Present+
19:07:44 <gregwhitworth> brecht_dr: you could open it?
19:07:49 <dbaron> Present+ gregwhitworth
19:07:53 <dbaron> Present+ masonf
19:07:58 <gregwhitworth> masonf: what do we do with invokers, we do click which are user activation
19:08:05 <dbaron> Present+ smhigley
19:08:08 <dbaron> Present+ jarhar
19:08:13 <dbaron> Present+ bkardell
19:08:16 <dbaron> Present+ nmn
19:08:21 <gregwhitworth> 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
19:08:34 <gregwhitworth> masonf: targeting a select is a new capability for an invoker
19:08:49 <bkardell_> bkardell_ has joined #openui
19:09:06 <sarah> present+
19:09:06 <bkardell_> present+
19:09:23 <gregwhitworth> 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
19:09:44 <gregwhitworth> masonf: I see, I don't see why the commandfor shouldn't be able to point to a select and that open the select
19:09:48 <masonf> q?
19:09:51 <gregwhitworth> masonf: and that is the user activation
19:09:53 <masonf> present+
19:09:53 <gregwhitworth> ack masonf
19:09:57 <gregwhitworth> ack gregwhitworth
19:10:35 <gregwhitworth> masonf: I don't think we NEED a resolution for this
19:11:05 <jarhar> gregwhitworth: so this is a noop api now?
19:11:18 <jarhar> masonf: if you call showpicker with no activation, it throws an exception right now.
19:11:39 <jarhar> gregwhitworth: i like having the artifact that we are resolving to keep the behavior as is
19:11:50 <jarhar> gregwhitworth: but we intentionally made the decision not to change the behavior
19:11:58 <jarhar> masonf: i was hoping for the opposite resolution
19:12:25 <jarhar> gregwhitworth: im not opposed to it either, but i dont see a strong reason to change the html spec
19:12:49 <sarah> q+
19:12:50 <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
19:13:00 <brecht_dr> brecht_dr has joined #openui
19:13:09 <jarhar> masonf: that was something from westbrook, which was having it open by default on page load. that would not be possible without this
19:13:28 <jarhar> gregwhitworth: i can't recall. when we focus in on the select does it happen or is it with the keyboard?
19:13:32 <jarhar> masonf: keyboard
19:13:47 <jarhar> gregwhitworth: ok yeah. there are use cases where it forces you into a pick list by default
19:14:04 <brecht_dr> q+
19:14:08 <jarhar> gregwhitworth: so when this thing gets focused i would show that popup
19:14:17 <jarhar> gregwhitworth: i cant remember where i encountered this in salesforce
19:14:40 <jarhar> gregwhitworth: when we were talking about open forever, people were saying we want defaultopen, but people can programatically do it
19:15:04 <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
19:15:19 <jarhar> gregwhitworth: this would become a web compat concern since its throwing exceptions
19:15:26 <gregwhitworth> ack sarah
19:15:47 <gregwhitworth> sarah: the caveat is that the usecases are on editable comboboxes with open on focus
19:16:00 <gregwhitworth> sarah: there are things where we want to keep them open all the time while you're typing
19:16:26 <brecht_dr> q-
19:16:27 <gregwhitworth> sarah: the other is when you have teaching UI and you have a thing that we open programmatically
19:16:46 <dbaron> +1 to the teaching UI case (which I was thinking about mentioning)
19:16:57 <sarah> ack me
19:17:37 <gregwhitworth> masonf: I have two examples from this discussion which is opening on load and teaching UI where it opens the select
19:18:22 <gregwhitworth> Proposed Resolution: There are real world usecases for opening a picker using require programmatic activation on a custom select
19:18:35 <masonf> +1
19:18:40 <gregwhitworth> Proposed Resolution: There are real world usecases for opening a picker using programmatic activation on a custom select
19:18:52 <brecht_dr> +1
19:18:52 <gregwhitworth> RESOLVED: There are real world usecases for opening a picker using programmatic activation on a custom select
19:18:54 <sarah> +1
19:19:01 <gregwhitworth> github-bot, take up https://github.com/openui/open-ui/issues/1118
19:19:01 <github-bot> Topic: select: provide a way for authors to define the string value of rich options
19:19:01 <github-bot> OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1118.
19:19:33 <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
19:20:01 <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
19:20:25 <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
19:20:31 <gregwhitworth> q+
19:20:48 <masonf> q+
19:20:56 <gregwhitworth> https://open-ui.org/components/combobox.explainer/#introducing-search-attribute
19:20:59 <jarhar> gregwhitworth: i did not read this
19:21:11 <jarhar> gregwhitworth: we introduced this proposal for combobox, which is the search attribute for this problem
19:21:21 <jarhar> gregwhitworth: we were thinking about the same thing. should you be searching the email or the values or all of the contnet
19:21:53 <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
19:21:54 <brecht_dr> q+
19:22:00 <jarhar> gregwhitworth: on top of that prior to this we also had the filter
19:22:08 <jarhar> gregwhitworth: heres how youre going to search. are you wanting to remove them or jump to them?
19:22:15 <jarhar> gregwhitworth: just wanted to share those thinkings that we had
19:22:16 <gregwhitworth> ack gregwhitworth
19:22:16 <sarah> q+
19:22:18 <jarhar> q+
19:22:25 <jarhar> masonf: im glad you went first
19:22:30 <gregwhitworth> masonf: I'm glad you went first
19:22:49 <gregwhitworth> masonf: the attribute on each option I see it being a foot gun and changing the actual content vs the attribute
19:22:56 <gregwhitworth> masonf: you may not notice that it's broken
19:23:18 <gregwhitworth> masonf: if it's the attribute on the select
19:23:40 <gregwhitworth> ack masonf
19:23:44 <gregwhitworth> ack brecht_dr
19:24:02 <gregwhitworth> brecht_dr: I had same concern that masonf had and that people could do malicious things
19:24:38 <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
19:24:51 <gregwhitworth> brecht_dr: I don't see a large benefit in this usecase
19:25:02 <gregwhitworth> brecht_dr: you'll have to fix this in styles alone and not layout
19:25:04 <gregwhitworth> q+
19:25:08 <gregwhitworth> ack sarah
19:25:30 <gregwhitworth> sarah: going to that first, having to re-arrange with CSS and visual vs dom order has a11y issues
19:25:39 <masonf> reading-order FTW?
19:25:43 <gregwhitworth> sarah: then you create a conflict between good keyboard and good AT issues
19:26:05 <gregwhitworth> brecht_dr: I do know the CSS WG is working on reading-order?
19:26:14 <gregwhitworth> sarah: would the type-ahead be different
19:26:36 <gregwhitworth> sarah: also, having this weird gotcha that your visual markup will impact it seems weird to me
19:26:53 <gregwhitworth> sarah: the reason it is a bit more complex is that it is more complex than combobox search
19:27:13 <gregwhitworth> sarah: maybe you want the filter-ing string to catch names within certain values, etc
19:27:22 <gregwhitworth> sarah: it can be really valuable
19:27:40 <gregwhitworth> sarah: for this behavior and you touch one letter multiple times it filters through them
19:27:48 <masonf> q+
19:27:52 <gregwhitworth> sarah: when you're typing a longer string
19:28:03 <gregwhitworth> sarah: this gets a little more complex
19:28:09 <gregwhitworth> ack jarhar
19:28:39 <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
19:28:50 <brecht_dr> q+
19:28:53 <gregwhitworth> jarhar: given the existing attributes in content
19:29:14 <gregwhitworth> jarhar: if you want it to run a certain way you can try and implement it that way
19:29:26 <gregwhitworth> sarah: when you say go implement that do you mean the browser author or dev?
19:29:35 <jarhar> i got it
19:29:41 <jarhar> gregwhitworth: +1 to what you said sarah
19:29:50 <jarhar> gregwhitworth: theres a can of worms to unpack with the search existing on select
19:30:03 <jarhar> gregwhitworth: i want this aspect of this content to have a key for quick searching
19:30:15 <jarhar> gregwhitworth: i think thats what youre rasiing which is like xml style content to identify for searching
19:30:30 <jarhar> gregwhitworth: and then theres the orthogonal part which is hitting the same characters and different characters. thats getting into we need a filter
19:30:42 <jarhar> gregwhitworth: its the behavior that happens when youre typing. whehter it jumps or whether it does this
19:30:46 <sarah> q+
19:30:56 <jarhar> gregwhitworth: as you reason about that content what should the behavior take on? does it jump or filter? selects today jump
19:31:10 <jarhar> gregwhitworth: i dont think i want to get too in the weeds too quickly with having numerous things on the options
19:31:19 <jarhar> gregwhitworth: you could search the value or the pattern of the text content within
19:31:28 <jarhar> gregwhitworth: we could explore numerous. i dont think theres any one right path
19:31:33 <gregwhitworth> ack gregwhitworth
19:31:34 <jarhar> gregwhitworth: everything youre bringing up is valid
19:31:36 <gregwhitworth> ack masonf
19:31:46 <jarhar> masonf: we should remember that this isn't specced behavior at all right now.
19:32:11 <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
19:32:21 <gregwhitworth> masonf: determine what's in the buffer
19:32:36 <gregwhitworth> masonf: I've seen some good selects is it not only shown but it filters them
19:33:02 <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
19:33:18 <gregwhitworth> masonf: try later to ship an attribute but how to bind it with behaviors that are common
19:33:22 <gregwhitworth> q?
19:33:26 <gregwhitworth> ack brecht_dr
19:34:08 <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
19:34:15 <gregwhitworth> brecht_dr: that may be a more prominent usecase
19:34:44 <gregwhitworth> brecht_dr: it may sort of a reference like the selectedcontent element and have the items to be read while you're typing
19:34:57 <gregwhitworth> brecht_dr: I do see some different options on how this could go
19:35:26 <gregwhitworth> sarah: I do like having selectors determining what is the correct one
19:35:49 <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
19:36:01 <gregwhitworth> sarah: you need the text that is inserted vs value to be defined
19:36:08 <gregwhitworth> sarah: the search wouldn't work for that
19:36:28 <gregwhitworth> sarah: the more that you look at this it could cover the proposal
19:36:48 <gregwhitworth> sarah: on user data, we implemented this in our custom select so I'm very familiar with this
19:36:58 <gregwhitworth> sarah: the search algo is different vs editable and non-editable
19:37:24 <gregwhitworth> sarah: the timing of how you type determines if it's a different word or the same word, such as aardvark
19:37:45 <gregwhitworth> sarah: you can keep typing the same letter without timing you'll have issues and show/hide things on a timer
19:37:46 <gregwhitworth> q+
19:37:49 <gregwhitworth> ack sarah
19:38:17 <gregwhitworth> sarah: the tricky thing with user data are not asking people that use it vs the people building
19:38:25 <jarhar> i got it
19:38:39 <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?
19:38:55 <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
19:39:11 <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?
19:39:26 <jarhar> sarah: ive avoided making a difference between select and combobox because select is a combobox
19:39:41 <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
19:39:54 <jarhar> sarah: theres a difference between needing something you type in and not type in
19:40:41 <jarhar> gregwhitworth: i heard two thing: attribute typeahead solution should be incubated. the other is the v1 of select for this.
19:40:47 <jarhar> gregwhitworth: is there anything else i missed?
19:41:26 <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
19:41:32 <jarhar> gregwhitworth: are you saying that we need to have this for select v1?
19:41:46 <jarhar> sarah: i dont want to underestimmate how much people do thsi because i think people do this a lot
19:41:48 <brecht_dr> q+
19:42:05 <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.
19:42:15 <jarhar> gregwhitworth: then we'll end up being like heres how we want you to iterate on top of x
19:42:32 <jarhar> gregwhitworth: to masons point, heres where the behavioral filters can come in or not
19:43:01 <gregwhitworth> sarah: my worry is to separate the behavior and what text it's using and the text that it matches is more complex
19:43:04 <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
19:43:26 <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
19:43:49 <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?
19:43:58 <gregwhitworth> q?
19:44:01 <gregwhitworth> ack gregwhitworth
19:44:06 <jarhar> sarah: yeah theres options with big text in the middle and an option with some text above and below
19:44:21 <jarhar> masonf: so the alt text wouldnt count but the big text and subtext would count
19:44:35 <jarhar> masonf: so how often do people build things like that and that would help us prioritze fixing it
19:44:47 <gregwhitworth> q+
19:45:02 <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
19:45:11 <gregwhitworth> ack brecht_dr
19:46:00 <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
19:46:00 <jarhar> own hands. as you search for something its just the first string you find inside the option
19:46:05 <masonf> q+
19:46:33 <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
19:46:57 <sarah> q+
19:47:19 <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
19:47:27 <jarhar> gregwhitworth: we could be landing pattern 6 months later
19:47:33 <jarhar> gregwhitworth: this group could be riffing more on your specific scenario
19:47:42 <jarhar> gregwhitworth: you can quickly just start being iterative because that foundation is there
19:48:12 <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
19:48:18 <gregwhitworth> ack gregwhitworth
19:48:20 <gregwhitworth> ack masonf
19:48:29 <gregwhitworth> masonf: +1 to what gregwhitworth said and I do see this
19:48:44 <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.
19:48:45 <gregwhitworth> masonf: it took a while to ship the first thing and then we'll be able to quickly incrementally ship features
19:48:58 <gregwhitworth> scribenick: jarhar
19:49:32 <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
19:49:32 <jarhar> in the old select or new
19:49:40 <gregwhitworth> q?
19:49:42 <gregwhitworth> ack sarah
19:49:59 <jarhar> sarah: for things that come after v1, you can just ship a singular feature on its own? awesome! i think i agree
19:50:18 <jarhar> gregwhitworth: think of csswg, they had css 1 and 2 and 3. this is just getting customizable select out the door
19:50:30 <brecht_dr> q+
19:50:33 <jarhar> sarah: if you have something thats easy to get through standards it could be a 3 month fast follow
19:50:41 <jarhar> masonf: it needs to be backwards compatible and enhance
19:50:53 <gregwhitworth> ack brecht_dr
19:51:15 <jarhar> brecht_dr: just to respond to mason, i think thats a big benefit. if its backwards compatible and behaves the same,
19:51:36 <jarhar> brecht_dr: that makes it a bit more easy for developers to understand that im going for modern browsers rather than backwards compatible
19:51:49 <jarhar> gregwhitworth: sarah since yo uopeened this are you lookking for a resolution?
19:52:22 <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
19:52:40 <jarhar> gregwhitworth: i can bring in the person who helped write that from internal meetings. we can spread it across 3 people
19:53:00 <jarhar> masonf: i think it would be great to pull it out in a separate explainer
19:53:20 <jarhar> gregwhitworth: the second they introduced the search thing, calling that attribute search is actually confusing
19:53:30 <jarhar> gregwhitworth: ill go ahead and do that i dont think we need a proposed resolution
19:53:49 <gregwhitworth> Zakim, end meeting
19:53:49 <Zakim> As of this point the attendees have been brecht_dr, dbaron, gregwhitworth, masonf, smhigley, jarhar, bkardell, nmn, sarah, bkardell_
19:53:52 <Zakim> RRSAgent, please draft minutes
19:53:53 <RRSAgent> I have made the request to generate https://www.w3.org/2024/11/14-openui-minutes.html Zakim
19:54:00 <Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent.  Goodbye
19:54:00 <Zakim> Zakim has left #openui
20:01:17 <dbaron> Scribe+ jarhar
20:01:28 <RRSAgent> I have made the request to generate https://www.w3.org/2024/11/14-openui-minutes.html dbaron
20:03:18 <dbaron> s/i got it/Scribe+/g
20:03:22 <RRSAgent> I have made the request to generate https://www.w3.org/2024/11/14-openui-minutes.html dbaron