18:00:12 RRSAgent has joined #openui 18:00:16 logging to https://www.w3.org/2026/08/27-openui-irc 18:00:17 Zakim, start meeting 18:00:17 RRSAgent, make logs Public 18:00:19 please title this meeting ("meeting: ..."), gregwhitworth 18:00:27 meeting: Open UI Telecon 18:01:04 brecht_dr has joined #openui 18:01:07 jarhar has joined #openui 18:01:17 chair: Greg Whitworth 18:01:19 flackr has joined #openui 18:01:29 present+ 18:02:26 present+ 18:02:53 Present+ 18:03:09 present+ 18:03:13 present+ 18:04:39 FYI on Overscroll updates: https://github.com/openui/open-ui/pull/1507 18:05:55 github-bot, take up https://github.com/openui/open-ui/issues/1463 18:05:55 Topic: Should the step between be able to differ between each thumb when more than 2 thumbs 18:05:55 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1463 18:06:12 q? 18:06:15 brecht_dr: *explains issue* 18:07:42 q+ 18:07:57 gregwhitworth: when people were asking for this, did they have use cases? 18:08:04 ack gregwhitworth 18:08:27 brecht_dr: yes 18:08:47 brecht_dr: if there is no use cases, i feel like we should at least document that this was discussed if people want to reopen it later on 18:08:55 brecht_dr: but then at least we already thought about it and it showed up 18:09:05 brecht_dr: i dont see ?? use cases with different thumbs 18:09:13 gregwhitworth: does anyone disagree? 18:09:25 github-bot, take up https://github.com/openui/open-ui/issues/1462 18:09:25 Topic: Have a way for to have a maximum space between 18:09:25 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1462 18:09:42 brecht_dr: *introduces issue* 18:10:23 q+ 18:11:35 gregwhitworth: i recommend trying to get a v1 variant out that is the 90% use case. if its a new attribute theres no web compat concern. nothing stops you from including it in the explainer now 18:11:58 gregwhitworth: as it gets out there, some devs have started giving you isnights. it would be good for us to ship something 18:12:19 gregwhitworth: somebody from yamaha was working on range but it was a circular dial and they wanted haptics 18:12:37 gregwhitworth: we then can get it in peoples hands and then they could find out if they needed to go back into building it themselves 18:12:44 gregwhitworth: you know this control better than anybody 18:12:50 q+ 18:12:54 ack gregwhitworth 18:12:54 gregwhitworth: we can always add stuff, we should just get that 90% dialed in 18:13:07 brecht_dr: do you recommend that i add this one for a v1 explainer? or just leave it out for now 18:13:12 gregwhitworth: i would leave it out 18:13:42 gregwhitworth: if you have to include it because every design system has it, we can come back. adding an attribute youve got it in your head. i would try to keep it scoped and limited, were getting into some game theory here 18:14:14 gregwhitworth: the smaller the api surface the better for a first go around 18:14:20 anaskim has joined #openui 18:14:37 gregwhitworth: we know every attribute you add is going to be debated. being able to go into it with confidence that every design system uses this 18:14:52 gregwhitworth: adding another attribute later is easier 18:15:13 brecht_dr: its a small use case, so yeah if its better to start small then ill leave it out for now 18:15:30 gregwhitworth: we left select multiple off. multiple is very common 18:16:12 github-bot, take up https://github.com/openui/open-ui/issues/1461 18:16:13 Topic: Rangegroup two thumbs at the same time 18:16:13 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1461 18:16:24 brecht_dr: *introduces issue* 18:17:46 q+ 18:17:52 ack brecht_dr 18:17:56 q+ 18:18:01 jarhar: +1 to not doing multi touch 18:18:24 jarhar: I agree to not doing multi-touch, there isn't precedence for this 18:18:31 jarhar: I've also never tried to do this 18:18:37 ack jarhar 18:18:46 ack flackr 18:18:48 flackr: theres a bit of precedent here with scrolling 18:19:04 flackr: that you can have two different scrollers and in theory you could scroll those two things at the same time, but thats not what we do, we start a zoom gesture 18:19:05 Do we support sliding 2 *different* sliders at the same time? 18:19:34 gregwhitworth: i was thinking of when would you want this, and going back to time length thing, lets say you want a 1 hour meeting 18:19:39 gregwhitworth: pretend that range is a calendar thing 18:19:54 gregwhitworth: you can change the length of the time. you want that constrained and then slide the two handled 18:20:14 q+ 18:20:18 gregwhitworth: what may make sense in that case is by having a third thumb, thats in between and hidden, that allows you to move them both and keep the constraints 18:20:25 gregwhitworth: youre still putting one finger on the screen 18:20:33 q+ 18:20:35 gregwhitworth: it makes more sense - ive set my length and now i just want to move the time around 18:20:45 gregwhitworth: i like your time one because we can all imagine it 18:21:11 gregwhitworth: i do think figuring out a solution to that is important. not sure if it needs to be in v1. i could imagine a ton of debate on that 18:21:19 gregwhitworth: i would probably make it a v2 thing 18:21:26 ack anaskim 18:22:01 anaskim: something similar ive seen is when youre editing a video in your phone and you cant move both of the limits at the same time. you have to move one and then the other or the whole range. i dont think theres a lot of precedent for moving two sides at the same time 18:22:24 gregwhitworth: video editing is very similar. similar to a performance trace in devtools 18:22:30 gregwhitworth: theres a ton of use cases here, time range 18:22:31 ack brecht_dr 18:22:45 brecht_dr: next issue is about segment dragging 18:23:10 brecht_dr: for this we can just say that two fingers does pinch zoom 18:24:19 proposed resolution: dont support multitouch gesture to move two sliders at the same time 18:24:40 proposed resolution: dont support multitouch gesture to move two sliders at the same time by dragging two thumbs at the same time 18:25:22 RESOLVED: dont support multitouch gesture to move two sliders at the same time by dragging two thumbs at the same time 18:25:42 github-bot, take up https://github.com/openui/open-ui/issues/1460 18:25:42 Topic: Segment dragging on range inputs 18:25:42 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1460 18:25:54 brecht_dr: *introduces issue* 18:27:38 q+ 18:27:47 q+ 18:28:30 flackr: if were supporting this dragging in the middle feature that maybe clicking to move the thumb is more of a single thumb action or only when youre outside of a draggable range 18:28:45 flackr: i worry about linking an action to move a thumb with an action for moving both of the thumbs 18:29:04 flackr: im having a hard time reasoning about these three+ thumb cases. do you have real world examples of them? 18:29:22 flackr: in one of the previous issues i thought maybe it would be valuable to have different mins and maxes but i cant imagine such an application right now 18:30:06 gregwhitworth: the one i was going to bring up is for mixers - when you move the master it moves 5 others along with it 18:30:51 gregwhitworth: what youre saying rob, i think - if i touch i am either clicking or pressing and holding the thumb that changes the thumb location 18:31:06 gregwhitworth: if i press in the middle then it should not get magical and try to choose a thumb to move 18:31:13 gregwhitworth: clicking in the middle should basically be a prevent default 18:31:21 flackr: yeah and maybe theres a future where it ? that segment 18:31:38 q+ 18:32:01 gregwhitworth: if you have shaky hands or on a bumpy road that could make this hard 18:32:04 ack flackr 18:32:07 ack gregwhitworth 18:32:45 gregwhitworth: *visually demonstrates circular 2 thumb range slider* 18:33:40 gregwhitworth: how your clicks work on those thumbs matters after you ship it 18:33:47 ack brecht_dr 18:34:26 brecht_dr: one of the first things that people asked is can i make a thumb move when i click on the track. a lot of people expect that behavior. the form element that we have now is when you click on the track it moves the thumb, and people expect that for two thumbs 18:35:04 brecht_dr: another big question we get here is if you can drag the segment, should the segment become focusable? if youre a keyboard usable you probably want to select the first thumb and then the second and then the second thumb 18:35:14 brecht_dr: you want a keyboard user to be able to drag the segment as well, at least thats what i think 18:35:19 q+ 18:35:22 brecht_dr: its definintely worth thinking about 18:35:36 gregwhitworth: on the multi range - the focus one should be a separate issue on its own. going back to the thing about segments 18:35:49 gregwhitworth: with the native ones, im not aware of a native html one which allows multiple thumbs 18:36:05 gregwhitworth: we can still be web compatible with - if youre clicking an area thats not between the two 18:36:47 gregwhitworth: then it would move the closest thumb. but not move either thumb if you click in between them 18:38:03 q+ 18:39:16 ack gregwhitworth 18:39:25 flackr: it makes the click action consistent with the drag action 18:39:29 ack vmpstr 18:39:32 vmpstr: i dont know if i agree with that 18:39:56 vmpstr: purely as a user, i always expect that a range with a 2 thumb thing, when i click outside of that range i am going to center that range over where i clicked 18:40:03 vmpstr: i can only increase using this which is really weird to me 18:40:17 vmpstr: theres a priority of the size of this is more important than its location 18:40:36 vmpstr: calendar events are half an hour, if i click around then im intending to move this block around because the size of it is important to me 18:40:40 q+ 18:40:56 vmpstr: theres cases for both but purely opinionated is that as a user im always expecting the center to move rather than the endpoints 18:41:13 q+ 18:41:16 flackr: what i like about that is that its consistent. anything outside of the thumbs is move the range, and then on the thumb is move the thumb 18:41:31 brecht_dr: one of the most typical ones is price sliders. minimum and maximum price 18:41:59 brecht_dr: there i see a lot of use cases where i want to increase the min an bit or the max, but dont want to drag the range 18:42:02 q+ 18:42:12 brecht_dr: i can still see use cases to click on the track to change one thumb 18:42:28 ack brecht_dr 18:42:32 brecht_dr: video and time ranges 18:42:37 brecht_dr: really depends on the use case 18:42:43 brecht_dr: im guessing theres no way to make both possible 18:42:46 ack flackr 18:43:07 flackr: maybe this needs to be a mode on the dragger. to say the intended use case is one where you care about the endpoint and one is about the range and the application can decide 18:43:17 brecht_dr: i like that idea personally but people dont like to add attributes 18:43:25 q- 18:43:31 gregwhitworth: if you ground in the use cases. i dont necessarily follow 18:44:10 gregwhitworth: its good for us to align on terminology. vlad is saying that if ive selected the calendar whatever item, and then clicked on another range, i expect it to move it to the other range 18:44:30 gregwhitworth: weve seen the one with price, i just want to click one end and then click the other 18:44:43 gregwhitworth: if you have solid enough use cases, it will be hard for someone to argue that you shouldnt support them 18:44:54 q+ 18:44:59 ack gregwhitworth 18:45:02 ack brecht_dr 18:45:16 brecht_dr: can the proposed resolution in this case to look into a mode and create a new issue to create a name for that mode? 18:45:30 flackr: the attribute could be mode, draggable, i dont know, but something 18:45:45 brecht_dr: theres so many directions here on calling it a mode or draggable 18:45:58 brecht_dr: i dont want to just write something in the explainer, this one should be bikeshedded more. draggable is something that exists already 18:46:13 brecht_dr: maybe its too niche or small for this 18:46:30 flackr: draggable is weird because its not at all the same thing but it does interefere with the behavior here 18:46:42 gregwhitworth: i dont think you need to create a new one 18:46:49 gregwhitworth: there should be some way to change modes 18:47:24 gregwhitworth: outside of the impl oddities of draggable, we were just talking about how the segment should always be draggable, so adding draggable is confusing. id argue against that for several reasons 18:47:26 proposed resolution: There should be a way to change modes, making the segments draggable versus having a click to move the thumbs. This to cover usecases where the range is more important versus start and and end points 18:48:15 flackr: i imagine that drag is going to have a meaning in both of these modes 18:48:27 flackr: in one mode youre dragging the segment, in the other youre dragging the thumb 18:48:57 flackr: if clicking moves the nearest thumb position, then dragging should also move the thumb to where youre dragging 18:49:07 proposed resolution: There should be a way to change modes, making the segments draggable versus having a click/click+drag to move the thumbs. This to cover usecases where the range is more important versus start and and end points 18:49:36 vmpstr: we have very few data points in this room of whats the right thing. we could look out there and how do current cases behave? if 90+% of cases do it one way then we could just punt this and do it that way. but if its more like 50/50 then a mode is a good way to go 18:49:40 brecht_dr: and then we can discuss the default 18:50:20 flackr: in mac it moves the thumb to where my cursor is and starts dragging it 18:51:16 gregwhitworth: if you do that research, then mode is something that you can punt on. it would allow you to iterate more quickly 18:51:43 brecht_dr: ill add documentation on what libraries are doing 18:51:55 brecht_dr: less frequent in libraries but more common in apps 18:52:25 github-bot, take up https://github.com/openui/open-ui/issues/1459 18:52:25 Topic: Link input elements with a slider value 18:52:25 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1459 18:52:41 brecht_dr: *introduces issue* 18:53:01 q+ 18:53:25 q+ 18:53:57 jarhar: I think this could be a separate thing, even with a single thumb it's useful 18:54:13 jarhar: in iOS if you have an alpha slider and you adjust it you update the input 18:54:42 jarhar: before I saw the contribution I thought it's the correct way to have semantic linking so you can just type in the answer 18:54:53 gregwhitworth: +1 to it being a separate proposal 18:54:57 +1 18:55:10 gregwhitworth: weve started to dig into where steve is starting to go - native data binding, thats what were talking about 18:55:18 gregwhitworth: control-value() css thing is related 18:55:52 gregwhitworth: joey to your point i think it makes it a separate issue about how the data gets there. theres the range that i see everywhere where there may or may not be a tooltip where theres things at the bottom 18:56:12 gregwhitworth: the thing you brought up should be different in dom. when im in office or whatever different suites and they have a dropdown for zoom, im like just let me type in what i want 18:56:25 gregwhitworth: so im now curious brecht, should the dom just have that input from a better ux perspective 18:56:39 gregwhitworth: using the color input wheel, font size is always off to the side theres a range there 18:56:49 gregwhitworth: is that just part of the dom? and then the whole data binding thing is separate 18:56:53 gregwhitworth: i think its worth thinking about 18:57:05 q+ 18:57:05 gregwhitworth: if you solve data binding then you can say range doesnt have a sibling input by default 18:57:36 gregwhitworth: the only reason i say that is because i dont want to tackle data binding - i dont want to do this the simple solution, i think that invokers is going to be too simple, i want to solve data binding and pull in state management 18:57:39 gregwhitworth: its a can of worms 18:57:40 ack gregwhitworth 18:57:44 ack jarhar 18:57:48 ack brecht_dr 18:58:19 brecht_dr: you agree that it should be some separate track? i agree with joey that its not difficult to dual handle, its something you want for a single slider as well. should be tackled outside 18:58:50 brecht_dr: as a developer i would find it strange if you explain that single range doesnt have it and dual range does, there should be one solution that handles both, whether thats invokers or something else 18:58:53 q+ 18:59:00 brecht_dr: dual range slider you have a input by default and single you dont 18:59:32 brecht_dr: you want a switch for both these cases rather than just having it in enhanced range 18:59:43 ack gregwhitworth 18:59:55 brecht_dr: simply put i agree with joey - there should be a solution for input type range that also works with range group with two sliders 19:00:07 gregwhitworth: is range group always two? 19:00:10 brecht_dr: at least two 19:00:21 gregwhitworth: enhanced range is also i can have a single thumb right? 19:00:23 brecht_dr: no 19:00:25 gregwhitworth: i think you should 19:01:05 gregwhitworth: if you introduce a new element that makes it so i can do whatever i want then it should also work with one thumb 19:01:20 gregwhitworth: i dont think we want more than one range element, so sure its a range group its a group of one 19:03:14 brecht_dr: ill make sure that explainer gets updated and follows that idea 19:03:23 Zakim, end meeting 19:03:23 As of this point the attendees have been flackr, gregwhitworth, dbaron, brecht_dr 19:03:26 RRSAgent, please draft minutes 19:03:27 I have made the request to generate https://www.w3.org/2026/08/27-openui-minutes.html Zakim 19:03:30 I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent. Goodbye 19:03:33 Zakim has left #openui 20:39:49 stevenspriggs has joined #openui 20:56:41 stevenspriggs has joined #openui 21:25:17 stevenspriggs has joined #openui 21:44:42 stevenspriggs has joined #openui 21:58:57 stevenspriggs has joined #openui 22:14:48 stevenspriggs has joined #openui 22:33:27 stevenspriggs has joined #openui 22:49:33 stevenspriggs has joined #openui 23:13:04 stevenspriggs has joined #openui 23:41:32 stevenspriggs has joined #openui 23:49:52 stevenspriggs has joined #openui