Meeting minutes
<masonf> github-bot, take up openui/
[select] listbox toggle/beforetoggle
<github-bot> OK, I'll post this discussion to https://
jarhar: toggle/beforetoggle for customisable select, became no longer exposed after removing replacable popover
… firing on <select> would make sense.
PROPOSED RESOLUTION: Firing toggle/beforetoggle on <select>
masonf: always nervous about adding (??). Is there logic... timing relative to the cloning behaviour? Is there anything to be worried about?
jarhar: go look where it's defined for popovers and change it to say it fires on the select element oo
… can also do it for appearance:auto picker. Doing otherwise would mean its only for customisable select. I guess is fine but....
masonf: in spirit supportive as long as you don't run into issues.
<masonf> keithamus: I agree. Shouldn't be dependent on appearance:base. That would feel strange. Events based on style, even if it's kind of true.
<masonf> Proposed resolution: add toggle and beforetoggle events to the select element
<jarhar> Proposed resolution: add toggle and beforetoggle events to the select element
<keithamus> +1
RESOLUTION: add toggle and beforetoggle events to the select element
<masonf> github-bot, take up openui/
[select] Specifying direction for arrow key navigation
<github-bot> OK, I'll post this discussion to https://
una: selects don't always follow a vertical pattern, can open from bottom up, or right or left, unique nav direction like AirBnB select in tdemo
… at very least it would be good to specify the arrow direction
… select from bottom up, pressing arrow up goes to the end and down goes to the top, but the expectation is select opens below
… it would be even better with multi direction arrows but at very least specifying start and directionality
masonf: is this an accessibility issue? If you're not looking at it pushing down gets you the first one - does that cause issues, if it's rendered in a different way?
scott: no, it shouldn't - selects have worked that way for the last 30 years but if we wanted to have a new way to add this to the platform and expose it to AT that seems... that might not necessarily solve the problem as the listbox popup might appear above the triggering element, otherwise it appears below the fold
… so it might not always work out and not something to be changed with markup. I'm not sure about the use case pattern
… even the airbnb example, it's still a listbox of options, really if they wanted full grid functionality we should support grid popups.
… we walked about that at one point when this was a new element
… grid popups, dialog popups, combobox can open multiple types of things but html only allows a listbox popup right now
masonf: scott prompted me: sighted users where the popup can show above or below depending on where it is on the page sounds annoying to, push down and it's inverted, feels funny.
scott: any time keyboard interaction doesn't match user expectations - not even AT users but power keyboard users - that can be frustrating.
scott: It's not even just programmatic exposure, but visual queues - positioning might not even be enough. Changing how people _expect_ it to work can be frustrating.
una: I mostly agree, specifically keyboard users, what their expectations are, I think as a user I would expect different keyboard behaviour based on where it opens. I would expect movement and animation to follow my keyboard behaviour. Principle of good UX. That principle breaks when you cannot change the navigation.
… we also have new CSS properties like reading flow which can change how the DOM is ordered
… I could be wrong but when I've faced keyboard selection on these selects it's been unexpected. That's why I raised this issue.
sarah: part of this is when you build stuff where the visuals don't match the semantics, when you try to change the behaviour you change it for people who aren't looking at it.
… there's a possibility there, but it feels weird to have something like a combobox which is already complex to use, suddenly have that intentionally be horizontal - feels weird but I need to think through whether or not that is something that can functionally change.
… it's not communicated very often, e.g. aria-orientation.
… the big problem is grid like, like up-left-down-right. Jumping through 5 items at a time in one orientation, then you rotate your screen and its jumping through 3 at a time.
… people might not even notice they're missing options
… something that is actually a grid - e.g color pickers, hues, luminisoity, or date pickers which are generally grids. That's a different conversation, those controls would have to be grids.
masonf: the radial menu used on pinterest, what's the keyboard behaviour for those?
una: pinterest doesn't have this on their site, only app
masonf: what if you connect a keyboard to the app?
una: haven't tried
masonf: it's funny, maybe we should add diagonals?
jarhar: sarah mentioned color picker, and the picker would actually be a grid. So if we theoretically had a grid element, would it make sense to build a picker of options where the options are in a grid?
sarah: there are use cases but I don't know if it makes it up on the priority list.
sarah: date picker isn't really one because it's a dialog, you have cruft around the grid
sarah: Not just colours but pickers where left to right is hue and top to bottom is luminosity
jarhar: I'm thinking about select that's not a select, where you can put a grid in it that has options
sarah: yeah, the color picker, that's a select, semantically - you pick a value from a list. Aria allows this, grid is an allowed role that opens from a combobox. It exists, just not super common
scott: I think 2 things
… one. Regardless of what I said I'm not against this idea. Aside from where initial down/up key goes (I actually think it should always go to the first thing), outside of that the way to navigate around something... I could see an attribute to be added not just for keyboard behaviour but low level base styling that goes along with it.
… Like if theirs a 2D keyboard expectation then it should default to a grid layout style. Otherwise you could mark up something bi-directional that's still a single list.
<una> Could also see this for web games with controllers in the future 👀
scott: you wouldn't necessarily need a new grid element or something, it could be an attribute. As long as it's visual and programatically exposed.
… probably best to get user feedback on this too. Maybe this is coming from a place of hypothesis - it's a good start but we should get other users that have feedback on how this expects to work, and move forward from there.
… if they said "you know, scott was wrong" when we have something and I can shut up
una: Always pro getting developer feedback. With this feature being so new, there's not a lot of developers who have played with it
una: what kind of feedback would you want?
masonf: I heard user feedback. Mock it up and put it in front of users.
scott: yeah - even the behaviour as exists now, actual user feedback that shows user confusion would be a good motivation
masonf: yeah that's a good test case.
scott: the problem statement I heard was "visually it doesn't look like it behaves this way", but I'd like feedback from primary keyboard users that _also_ say that.
… my hypothesis is, based on working with keyboard users, I've never had that problem before
… I just want to see the data first.
una: I think it's a higher level issue, everything is surfaced with customisable select, we can make it how we want, but there's a bigger issue with navigation, e.g. navigating a grid, possibly web games in the future, interactive canvases, control how the keyboard works and not just up and down
… I could see it being a larger thing
scott: that's all valid, could very well be. Being this is scoped to just select right now, before we do anything like that, we need user data and a pathway forward where we're not changing keyboard behaviour just based on visuals
scott: I'm supportive, I just want to know how many people we will be serving on this.
… we had a bunch of data on customisable select that everyone wants this! We need the same kind of data for this.
una: this would be developer opt in, not a new default
scott: if developer has something provided by the platform that users don't want, then we have something developers don't want to use because users don't want it
masonf: shall we take it back to the issue?
una: yeah. I was having conversations with devs at CSSDay who said about this so I raised the issue.
masonf: this is with the current customisable select standard? Today? You could use JS to customise it?
jarhar: that's correct
masonf: so we could find a passionate user who wants this on their site?
una: that's good to know, I can build some prototypes.
<masonf> github-bot, take up openui/
[select] checkmark for select multiple
<github-bot> OK, I'll post this discussion to https://
jarhar: aleventhal gave feedback on my initial impl of select multiple. Instead of checkmarks we should have checkboxes, so options that aren't selected show an empty box so you can more easily tell
… reviewed a bunch of unicode characters (this is what we do for select single) there are some, but they're inconsistently aligned which made me not want to use them
… I posted images in the issue, on my machine they looked bad.
… so I think we should keep the current thing of the empty space with not selected options and the checkmark unicode for selected options
… then developers can add their own visuals,
masonf: +1 to leaving as is, those look ugly and developers would remove them
… having as close to single select styles as possible is probably a good thing, you can style things consistently and not have to cover each case
una: big +1 please don't add the empty checkmark box. Consistency is the best way forward. The existing multiselect does not have additional affordances, we don't need to add those, let it be up to the author.
scott: rational part of me wants to agree with everyone
<keithamus> +1
<frehner> +1
<scott> +1
<jarhar> Proposed resolution: Keep the single-select styles which just show a checkmark for selected options and an empty space for not-selected options
<sarah> +1
RESOLUTION: Keep the single-select styles which just show a checkmark for selected options and an empty space for not-selected options
<masonf> github-bot, take up openui/
[Range] What is the label?
<github-bot> OK, I'll post this discussion to https://
<masonf> github-bot, take up openui/
[Range] Attribute disagreements
<github-bot> OK, I'll post this discussion to https://
sarah: so the issue is around min/max on the range and inputs have separate min/max that might conflict with parent, so parent might have -10 and inner might have -50
sarah: should min/max be allowed on the inner at all?
masonf: I could make up a use case on the fly, e.g. 2 numbers, one has to be negative one positive, but I don't know of any practical use cases.
… my first impulse is the same as sarah - the group min/max should bound the inner, so in the example the inner would be clamped to -10
una: one example is a min value of 0 and max of 1 but a value of -0.5 might be used for easing curve, so that's possible. You might want to build with a larger min/max, but if you're trying to mentally think of one.
masonf: so there are use cases?
una: yes
<masonf> github-bot, take up https://
<github-bot> masonf, I can't comment on that because it doesn't look like a github issue to me.
<masonf> github-bot, take up openui/
[Link delegation] modifier key passthrough
<github-bot> OK, I'll post this discussion to https://
<una> r/0.5/-0.5*
frehner: prototyping and lightly implementing a userland impl of link delegation. In the process - the modifier key passthrough... it may be better to start with 1256 issue, which says can this be allowed to delegate to more than just link tags, can we delegate down to a button or checkbox.... shall we start with 1256?
<masonf> github-bot, take up openui/
[Link delegation] additional element support
<github-bot> OK, I'll post this discussion to https://
frehner: So link delegation is the idea of an area of content that when you click in the area of content, e.g. a "card", you click on it and it does a default action of navigating to somewhere else, and it has inner actions inside the card. So the default behaviour clicking on the card is to navigate but clicking on the interactables within will
enact those.
frehner: the explainer has many examples
… the a11y aspect is that this is a click only affordance, it introduces no other roles or semantics. Part of that being that the default action should already be visible, actionable, tabbable. So performing this click anywhere in the area will forward it to that item
… in the process with me playing and implementing this, my primary use case was more for tables, so clicking on a role selects the row - or a checkbox on the row, or a default action of a button.
… so my first question - does link delegation need to be opened up to other elements, e.g. button
<masonf> keithamus: already possible with script and label elements, right? So not a big deal for security? Does feel very weird. My security spidey sense is tingling.
frehner: same thought, it feels like making a dark pattern a little easier. But anyone can add an onclick handler to a div so... yeah
sarah: this is more of a general DX though - I've run into a lot of use cases where there is a button inside a card so I like this in the sense of cutting down those issues, but adding an onclick handler for a button isn't hard, in the same way it's hard for the link.
… like a click handler for a button is easy to copy onto a card, because you're specifying the behaviour once.
<masonf> keithamus: commandfor and popovertarget do things that you might want to happen. You can do them with setting imperative invoker in showPopover()
frehner: I haven't done a lot of research with other developers, but I agree it felt fairly simple. The only thing I have found is that the concept of this idea hasn't caught on a lot. There are lots of other impls where people are wrapping buttons or abs positioning a button or anchor
… so it might open the door to better impls but it might be too trivial
masonf: baking into the platform makes sure that people who do it poorly might have an easier way, so they avoid for e.g. button in button
sarah: fwiw I see that a lot
masonf: this pattern? Button in button
sarah: yes we have a lot of cards, which don't want to be wrapped in a button or link but people absolutely do. In theory it's easy to add an onclick handler and I don't know why people don't. But I do see it a lot
masonf: last week we talked about the interest invoker button which seems like it rhymes with this feature, it's a button like element
… so I'm wondering if not only additional elements but maybe also additional things - like it could delegate to interest action
keithamus: can it wrap or can it be adjacent?
masonf: in this case adjacent, but then this is about wrapping... so maybe I retract my comment
masonf: we could resolve not to do this now, it's not worth the effort, or what do people think?
<masonf> Proposed resolution: this is easy enough at the moment, so let's shelve this for now
frehner: the impression I am getting is that it's easy enough to do in userland so maybe it doesn't need to go through this process.
<keithamus> +1
<sarah> +1
<frehner> +1
RESOLUTION: this is easy enough at the moment, so let's shelve this for now
<masonf> github-bot, take up openui/
[Link delegation] modifier key passthrough
<github-bot> OK, I'll post this discussion to https://
frehner: left clicking on the area, and getting that link behaviour, you get the open in new tab and things like that, does that also include the cmd/ctrl click on the area, do the modifiers get passed through?
masonf: please pass through the modifier keys, I dislike it when it doesn't work
masonf: if delegating the modifier keys breaks some other use case? Passing a long the modifier key or not doing anything with it... I am wondering if that's true.
… I don't know why you wouldn't
I agree it's annoying when modifier keys don't get passed.
frehner: I agree, I would agree to resolve on that.
<masonf> Proposed resolution: pass along the modifier keys
<frehner> +1
sarah: when places have fake links that aren't real links... I hate it
<keithamus> +1
<sarah> +1
RESOLUTION: pass along the modifier keys
<masonf> github-bot, take up openui/
[Link delegation] does the target get :hover, :active styles?
<github-bot> OK, I'll post this discussion to https://
frehner: again in playing with this I was wondering, when you hover over the card should the hover/active states be passed along down to the delegate to indicate at least the visual affordance
frehner: so indicate I can perform this action and this is the action I am interacting with
frehner: I have a codepen... in a different comment
frehner: it does feel weird to have it as the whole card, but it does help to figure out what link is going to be activated.
masonf: my vote would be no. You can do it with :has - on the link delegate, no? The other way around is not true, if you want to turn them off you'd have a harder time trying to undo that behavior. So maybe the answer is no
<masonf> keithamus: I agree but I think there's a middle ground. Add a pseudo class like :link-delegate-active on the link. Don't reuse
<masonf> masonf: I like that idea
frehner: that was another thought I had, I like it too, it allows any styles to contain all of that, to not worry about using :has - could be messy as far as getting selectors correct, delegate active and so on.
masonf: simplifies everything and makes something possible.
<masonf> Proposal: Add :link-delegate-active and :link-delegate-hover instead
<keithamus> +1
<frehner> +1
RESOLUTION: Add :link-delegate-active and :link-delegate-hover instead