Meeting minutes
<gregwhitworth> FYI on Overscroll updates: openui/
<gregwhitworth> github-bot, take up openui/
Should the step between be able to differ between each thumb when more than 2 thumbs
<github-bot> OK, I'll post this discussion to openui/
brecht_dr: *explains issue*
gregwhitworth: when people were asking for this, did they have use cases?
brecht_dr: yes
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
brecht_dr: but then at least we already thought about it and it showed up
brecht_dr: i dont see ?? use cases with different thumbs
gregwhitworth: does anyone disagree?
<gregwhitworth> github-bot, take up openui/
Have a way for <rangegroup> to have a maximum space between
<github-bot> OK, I'll post this discussion to openui/
brecht_dr: *introduces issue*
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
gregwhitworth: as it gets out there, some devs have started giving you isnights. it would be good for us to ship something
gregwhitworth: somebody from yamaha was working on range but it was a circular dial and they wanted haptics
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
gregwhitworth: you know this control better than anybody
gregwhitworth: we can always add stuff, we should just get that 90% dialed in
brecht_dr: do you recommend that i add this one for a v1 explainer? or just leave it out for now
gregwhitworth: i would leave it out
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
gregwhitworth: the smaller the api surface the better for a first go around
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
gregwhitworth: adding another attribute later is easier
brecht_dr: its a small use case, so yeah if its better to start small then ill leave it out for now
gregwhitworth: we left select multiple off. multiple is very common
<gregwhitworth> github-bot, take up openui/
Rangegroup two thumbs at the same time
<github-bot> OK, I'll post this discussion to openui/
brecht_dr: *introduces issue*
jarhar: +1 to not doing multi touch
<gregwhitworth> jarhar: I agree to not doing multi-touch, there isn't precedence for this
<gregwhitworth> jarhar: I've also never tried to do this
flackr: theres a bit of precedent here with scrolling
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
<dbaron> Do we support sliding 2 *different* sliders at the same time?
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
gregwhitworth: pretend that range is a calendar thing
gregwhitworth: you can change the length of the time. you want that constrained and then slide the two handled
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
gregwhitworth: youre still putting one finger on the screen
gregwhitworth: it makes more sense - ive set my length and now i just want to move the time around
gregwhitworth: i like your time one because we can all imagine it
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
gregwhitworth: i would probably make it a v2 thing
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
gregwhitworth: video editing is very similar. similar to a performance trace in devtools
gregwhitworth: theres a ton of use cases here, time range
brecht_dr: next issue is about segment dragging
brecht_dr: for this we can just say that two fingers does pinch zoom
proposed resolution: dont support multitouch gesture to move two sliders at the same time
<brecht_dr> proposed resolution: dont support multitouch gesture to move two sliders at the same time by dragging two thumbs at the same time
RESOLUTION: dont support multitouch gesture to move two sliders at the same time by dragging two thumbs at the same time
<gregwhitworth> github-bot, take up openui/
Segment dragging on range inputs
<github-bot> OK, I'll post this discussion to openui/
brecht_dr: *introduces issue*
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
flackr: i worry about linking an action to move a thumb with an action for moving both of the thumbs
flackr: im having a hard time reasoning about these three+ thumb cases. do you have real world examples of them?
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
gregwhitworth: the one i was going to bring up is for mixers - when you move the master it moves 5 others along with it
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
gregwhitworth: if i press in the middle then it should not get magical and try to choose a thumb to move
gregwhitworth: clicking in the middle should basically be a prevent default
flackr: yeah and maybe theres a future where it ? that segment
gregwhitworth: if you have shaky hands or on a bumpy road that could make this hard
gregwhitworth: *visually demonstrates circular 2 thumb range slider*
gregwhitworth: how your clicks work on those thumbs matters after you ship it
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
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
brecht_dr: you want a keyboard user to be able to drag the segment as well, at least thats what i think
brecht_dr: its definintely worth thinking about
gregwhitworth: on the multi range - the focus one should be a separate issue on its own. going back to the thing about segments
gregwhitworth: with the native ones, im not aware of a native html one which allows multiple thumbs
gregwhitworth: we can still be web compatible with - if youre clicking an area thats not between the two
gregwhitworth: then it would move the closest thumb. but not move either thumb if you click in between them
flackr: it makes the click action consistent with the drag action
vmpstr: i dont know if i agree with that
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
vmpstr: i can only increase using this which is really weird to me
vmpstr: theres a priority of the size of this is more important than its location
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
vmpstr: theres cases for both but purely opinionated is that as a user im always expecting the center to move rather than the endpoints
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
brecht_dr: one of the most typical ones is price sliders. minimum and maximum price
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
brecht_dr: i can still see use cases to click on the track to change one thumb
brecht_dr: video and time ranges
brecht_dr: really depends on the use case
brecht_dr: im guessing theres no way to make both possible
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
brecht_dr: i like that idea personally but people dont like to add attributes
gregwhitworth: if you ground in the use cases. i dont necessarily follow
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
gregwhitworth: weve seen the one with price, i just want to click one end and then click the other
gregwhitworth: if you have solid enough use cases, it will be hard for someone to argue that you shouldnt support them
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?
flackr: the attribute could be mode, draggable, i dont know, but something
brecht_dr: theres so many directions here on calling it a mode or draggable
brecht_dr: i dont want to just write something in the explainer, this one should be bikeshedded more. draggable is something that exists already
brecht_dr: maybe its too niche or small for this
flackr: draggable is weird because its not at all the same thing but it does interefere with the behavior here
gregwhitworth: i dont think you need to create a new one
gregwhitworth: there should be some way to change modes
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
<brecht_dr> 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
flackr: i imagine that drag is going to have a meaning in both of these modes
flackr: in one mode youre dragging the segment, in the other youre dragging the thumb
flackr: if clicking moves the nearest thumb position, then dragging should also move the thumb to where youre dragging
<brecht_dr> 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
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
brecht_dr: and then we can discuss the default
flackr: in mac it moves the thumb to where my cursor is and starts dragging it
gregwhitworth: if you do that research, then mode is something that you can punt on. it would allow you to iterate more quickly
brecht_dr: ill add documentation on what libraries are doing
brecht_dr: less frequent in libraries but more common in apps
<gregwhitworth> github-bot, take up openui/
Link input elements with a slider value
<github-bot> OK, I'll post this discussion to openui/
brecht_dr: *introduces issue*
<gregwhitworth> jarhar: I think this could be a separate thing, even with a single thumb it's useful
<gregwhitworth> jarhar: in iOS if you have an alpha slider and you adjust it you update the input
<gregwhitworth> 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
gregwhitworth: +1 to it being a separate proposal
<brecht_dr> +1
gregwhitworth: weve started to dig into where steve is starting to go - native data binding, thats what were talking about
gregwhitworth: control-value() css thing is related
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
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
gregwhitworth: so im now curious brecht, should the dom just have that input from a better ux perspective
gregwhitworth: using the color input wheel, font size is always off to the side theres a range there
gregwhitworth: is that just part of the dom? and then the whole data binding thing is separate
gregwhitworth: i think its worth thinking about
gregwhitworth: if you solve data binding then you can say range doesnt have a sibling input by default
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
gregwhitworth: its a can of worms
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
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
brecht_dr: dual range slider you have a input by default and single you dont
brecht_dr: you want a switch for both these cases rather than just having it in enhanced range
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
gregwhitworth: is range group always two?
brecht_dr: at least two
gregwhitworth: enhanced range is also i can have a single thumb right?
brecht_dr: no
gregwhitworth: i think you should
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
gregwhitworth: i dont think we want more than one range element, so sure its a range group its a group of one
brecht_dr: ill make sure that explainer gets updated and follows that idea