IRC log of openui on 2024-11-14
Timestamps are in UTC.
- 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