18:51:50 RRSAgent has joined #openui 18:51:54 logging to https://www.w3.org/2024/01/11-openui-irc 18:56:15 zandermax has joined #openui 18:58:30 brecht_dr has joined #openui 18:58:35 lukew has joined #openui 18:58:38 present+ 18:58:57 Zakim, start meeting 18:58:57 RRSAgent, make logs Public 18:58:59 please title this meeting ("meeting: ..."), gregwhitworth 18:59:05 meeting: Open UI Telecon 18:59:21 gregwhitworth has changed the topic to: https://github.com/openui/open-ui/blob/main/meetings/telecon/2024-01-11.md 19:00:25 flackr has joined #openui 19:00:51 scribenick: hdv 19:00:52 present+ 19:00:57 masonf has joined #openui 19:01:11 present+ 19:01:19 present+ 19:01:19 present+ 19:01:27 chair: Greg Whitworth 19:02:04 jarhar has joined #openui 19:02:08 scotto_ has joined #openui 19:02:22 github-bot, take up https://github.com/openui/open-ui/issues/971 19:02:22 Topic: [combobox] Should we allow a button child to control the dropdown? 19:02:22 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/971. 19:02:29 present+ 19:03:04 lukew: for selectlist, one of the use cases was a split button design, so based on the type attribute you could choose what it controls 19:03:13 q+ 19:03:15 lukew: my question is if we should allow that also for combobox? 19:03:16 q+ 19:03:50 masonf: I'm of two minds… first thought: haven't seen a component like that (text input + button to show dropdown + button that does something else), that would make me think 'no' 19:04:03 masonf: but on the other hand, it would make sense to have a similar approach between selectlist and combobox 19:04:43 gregwhitworth: me and @@@ discussed this yesterday 19:05:07 gregwhitworth: the current select kind of pseudo-behaves in this way, with an arrow 19:05:20 gregwhitworth: issue would be focus management, when someone would want to type and use the button 19:05:37 q+ 19:05:45 gregwhitworth: technically you would invoke the button but would also expect to type on the combobox… select already does this today 19:05:50 una has joined #openui 19:05:58 gregwhitworth: feels like a bad paradigm to introduce, given the key use case of the combobox 19:06:02 present+ 19:06:34 gregwhitworth: split button feels like it introduces a third problem, theoretically feasible 19:06:41 masonf: accessibility is the key thing 19:06:42 q? 19:06:45 ack masonf 19:06:47 ack gregwhitworth 19:06:50 present+ 19:06:50 ack scotto_ 19:07:08 q+ 19:07:13 s/@@@/sudheer 19:07:41 ack una 19:07:47 buttons are to combobox as soda is to calzone 19:07:47 scotto_: just because I like two things, doens't mean I need them in the same thing. We can have things that are siblings, that can be fine 19:07:57 we were going to put soda into calzones 19:08:18 q+ 19:08:22 una: missed first bit, sounded like we were going to remove split button in combobox? seems to be like this is a common use case we should be solving for? 19:08:33 q+ 19:08:37 ack scott 19:09:09 gregwhitworth: it was one of the things where we won't block it, technically it would work, but just worried that we would have three different focus behaviour and this is a pattern I don't think we see a lot in the wild? 19:09:19 una: I've seen them on dropdowns for sure, usually it's a menu triggered by the button 19:10:13 una: one example is amazon.com, the main search bar there has a split button that is basically a search input but on the left of that a dropdown that has departments and ways to filter down search 19:10:26 una: but that could be a visual thing only, built technically out of multiple components 19:10:52 q? 19:10:54 ack masonf 19:11:04 gregwhitworth: great example… yes seems like that could be multiple components that are visually grouped together 19:11:18 masonf: would say the one on amazon is a combobox and a select 19:11:48 una: yes, it's interesting… it's multiple components and it looks visually like one piece 19:11:50 q? 19:12:41 +1 on not introducing split button for combobox in general, but allowing this for other UI elements such as selectlist 19:12:46 gregwhitworth: not sure about proposed resolution… sounds like we won't actually block split buttond? 19:12:57 lukew: I think it wouldn't make sense to have type=selectlist inside of combobox 19:13:31 gregwhitworth: like on amazon, when you invoke text element, is when the popup target is invoked… whatever that needs to be we should update it to 19:14:06 masonf: I would propose two things: we should rename that to type=select… for this issue, based on this discussion, any button that is inside the combobox should trigger the popup, would also eliminate the need to pick another attribute 19:14:37 gregwhitworth: would it be first or any? 19:14:40 lukew: I think any? 19:14:43 q+ 19:14:55 ack una 19:15:03 una: I think it's hard to have this discussion without having any examples of this 19:15:10 una: does anyone know of an example of a combobox that has a split button? 19:15:27 gregwhitworth: no… maybe this is where we're going back… combobox should still be theoretically extensible 19:15:49 gregwhitworth: I should theoretically be able to pull of this behaviour with a button type=select 19:15:54 s/of/off 19:16:17 lukew: that's what I'm leaning towards… let buttons just behave like buttons would normally behave, without extra attributes 19:16:29 masonf: you mean any button inside combobox triggers the popover? 19:16:42 lukew: no only that button would do what it would nornally do, including nothing 19:17:17 Proposed resolution: any button inside a combobox triggers the popover. 19:18:22 gregwhitworth: problem with 'any'… if author adds tags and the tag can be deleted with an 'x' button… would that cause issues? 19:19:01 gregwhitworth: most design systems have a pills/tags element where the individual elements can be deleted… and that could be used and need to be removeable in a combobox, would that open/close popup? 19:19:09 una: or if you had predefined answers 19:19:24 una: or an accordion of options that could be hidden 19:19:32 masonf: none of these sound like comboboxes, more like very fancy selects? 19:19:39 gregwhitworth: could totally be a combobox 19:19:54 gregwhitworth: eg when tagging issues on stackoverflow 19:20:08 masonf: but those pills can't be inside of the text input, right? text input is text? 19:20:28 gregwhitworth: we might need a new issue for this? 19:20:37 q+ 19:21:03 una: even in the amazon example… the combobox has a search bar with some predefined options… the first few options are things you already searched for and you can press an X that removes that suggestion 19:21:19 masonf: the additional things you can do are in the option not in the text box? 19:21:37 masonf: allowing for more than just text in the text box could open a whole can of worms 19:21:40 q+ 19:21:46 ack keithamus 19:22:03 keithamus: on GitHub, if you click on a repository that you own and click the cog you get pills… our accessibility team said it was an inaccessible pattern 19:22:28 keithamus: you effectively have a list of tokens/topics before your textareas, your textarea moves, the topic gets added as a list 19:22:55 s/pills/pills in the section where you can add topics 19:23:00 q+ 19:23:02 ack flackr 19:23:15 flackr: the Gmail compose box has a similar pattern, addresses become pills as you complete them 19:23:42 q+ 19:23:45 masonf: not discounting these are real things… just wonder as we're building a web standard that allows for building these things, how can we do it, what does it return, just the text or also the pills? 19:24:01 keithamus: the pills thing seems to be like a totally different form control that we might need to spec differently? 19:24:04 ack masonf 19:24:08 masonf: sounds like a form associated custom element 19:24:37 gregwhitworth: sounds like this problem would require us to solve multi select / combobox 19:25:04 gregwhitworth: the amount of scenarios in which pills being in the text input… by all means if you say it only takes text, we probably found another gap in the platform? 19:25:08 q+ 19:25:25 gregwhitworth: people are probably going to go do this 19:26:03 gregwhitworth: this issue is probably tangential to whether split button works in combobox 19:26:06 q? 19:26:10 ack gregwhitworth 19:26:28 lukew: you don't necessarily need the input to have children… you could have them as children to the combobox element 19:26:40 lukew: that would also solve the issue of having interactive content as children, that's kind of allowed 19:26:55 lukew: though depends on whether combobox counts as interactive 19:27:11 q- 19:27:21 lukew: if we just say all buttons triggger it, it limits use cases, it means if you want a button that doesn't open it, you have to preventDefault, which is an ordeal 19:27:33 q+ 19:27:50 akeerthi has joined #openui 19:28:58 gregwhitworth: whatever select has defined, we should probably do it for combobox too, not arbitrary block it, and look at any gaps there may be 19:29:04 masonf: maybe type=popover, that explains what it is going to do 19:29:12 masonf: and could be shared between combobox and select 19:29:24 gregwhitworth: I like that, feels less arbitrary than having type=combobox and type=select 19:29:46 gregwhitworth: so we probably come up with a name that applies to selectlist and combobox 19:29:56 Proposed resolution: any button with type=popover inside a combobox will trigger the popover. Other buttons will not. 19:30:42 gregwhitworth: maybe change to “combobox or select” so thatit applies to both ? 19:30:53 Proposed resolution: for stylable use