– DRAFT –
Open UI

<keithamus> github-bot, take up openui/open-ui#226

Token feature, or something like that.

<github-bot> OK, I'll post this discussion to openui/open-ui#226

<lwarlow> I vote we close this issue.

keithamus: *presents issue*

bkardell: i think we should close this

<lwarlow> +1

proposed resolution: close this issue for now

gregwhitworth: theres no champion, but not sure if we should close this

gregwhitworth: i dont want it to look like openui doesnt think we should do this

<keithamus> proposed resolution: We don't have a current champion, so we'll close this as not planned.

<gregwhitworth> +1

<bkardell> +1

RESOLUTION: We don't have a current champion, so we'll close this as not planned.

lwarlow: i dont know if this is something that openui wants to take up. a token or chip or various different name for it, they dont seem to me like they have semantic meaning

lwarlow: maybe they have use cases we should go after

lwarlow: generally arent they just spans with maybe a button?

gregwhitworth: can we debate this when it has a champion?

<bkardell> it is the kind of thing a champion would need to provide which is why I suggested closing it

gregwhitworth: i will happily debate you on this

<bkardell> this sounds like greg is weakly championing it :)

keithamus: we can park it and figure out when anyone wishes to resurface it

<keithamus> github-bot, take up openui/open-ui#1118

select: provide a way for authors to define the string value of rich options

<github-bot> OK, I'll post this discussion to openui/open-ui#1118

<keithamus> jarhar: I think this would be cool, I just don't know how to put this in HTML markup in a way which works with WHATWG.

sarah: the feature is a thing that in fluent we need to be able to use it, but yeah idk what the best way to mark this up is

sarah: in the past we threw around - the label attribute. repurpose label in stylable select and combobox because its an attribute that already exists and its useless

sarah: but its already an attribute and already does a thing

sarah: to go over why its needed: stylable select in the dropdown of options you have a rich set of stuff and the actual name which is the thing you care about but theres more information like the email, status, office number, etc

sarah: so that could show up in the select menu but when you select something you only want the name to show up

<keithamus> jarhar: you mention you want it to show up in the button

<keithamus> sarah: yes

<keithamus> jarhar: in the dropdown? Not when it's rendered in the button

<keithamus> sarah: generally

<keithamus> sarah: what's rendered in the button can be customised. But especially when we move to filterable/comboboxes we need more than a simple string - when you filter you want to define "this is the string that mathces"

<keithamus> sarah: you only want that to match based on the relevant string, the rest is ancilliary.

<keithamus> jarhar: sounds like "typeahead", e.g. type to focus an option, "text" used for matching for filtering, then there's what's rendered in the option in the dropdown and what's rendered in the button. Those 4 right?

<keithamus> sarah: typeahead and type to filter are conceptually the same, just whether or not there's an input or you're just hitting keys.

lwarlow: i think

lwarlow: ideally label would be the attribute for this, but it currently already replaces the rendered thing

lwarlow: thats already a behavior that someone somewhere is going to be relying on

lwarlow: i think a new attribute that we'll name "bruce" for now which takes a string seems like the way to do it

lwarlow: an attribute on the option seems fine here

lwarlow: its deliberately only meant to be a string, so it doesnt matter if its an attribute

lwarlow: i think attribute values can contain unicode characters

<lea> +1 for label, just posted in the issue

lwarlow: so youll at least get non ascii stuff in there for internationalization

gregwhitworth: ironically sarah just wanted to go back to what we propsoed in 2024

gregwhitworth: i feel like we could come up with solutions on the call all day

gregwhitworth: luke even with the combobox proposal, you could still caveat that because were going to introduce a new "foo" that works on x elements, lets pick on select

gregwhitworth: you could add the search or bruce attribute

gregwhitworth: at that point, you can leverage the labels that are already there

gregwhitworth: and thus you dont actually dont have a compat issue

gregwhitworth: ironically yesterday in focusgroup channel, brought up wanting to do this for file explorer and typing ahead it changes focus

gregwhitworth: theres some overlap but not all at the same time

gregwhitworth: i dont think were going to get consensus until someone puts forward a concrete proposal

<Jacques> +1

<bkardell> what's wrong with bruce?

keithamus: i think thats reasonable

gregwhitworth: maybe we could set up with a working session or two and jam on an explainer real quick and make sure it doesnt collide with focusgroup

sarah: yeah with menus too

lwarlow: one thing that might be worth trying to do now is getting a use counter for label on options in base appearance mode

<bkardell> 0

<bkardell> +1

dandclark: we talked about this in issue number 1115

sarah: we talked about changing label for stylable select. in theory i think that was discussed, could we repurpose label

<dandclark> s/???/openui/open-ui#1115

<gregwhitworth> I mean customizable select is still relatively low in adoption right now: https://chromestatus.com/metrics/webfeature/timeline/popularity/342

sarah: i have no personal preference for label. i thought from before that maybe whatwg people would dislike more attributes

<keithamus> jarhar: probably can't change it for auto, but can for base appearance. Be surprised if there was a result otherwise.

<keithamus> jarhar: adding a use counter is effectively free, if it's useful

<keithamus> proposed resolution: Workshop a concrete design for this, meanwhile investigate adding a use counter for label.

lwarlow: worth looking at optgroups

lwarlow: would be interesting if you could filter by the group name and it filters

lwarlow: optgroups can have a legend that isnt just plain text, so we might want to account for it there too

<lwarlow> +1

lwarlow: optgroups also already have a label attribute, although idk what happens when you have both label and legend

<sbender> +1

<sarah> +1

RESOLUTION: Workshop a concrete design for this, meanwhile investigate adding a use counter for label.

<keithamus> github-bot, take up openui/open-ui#1189

[menu] How should we group checkboxes and radios, and how should we decide if they are checkboxes or radios?

<github-bot> OK, I'll post this discussion to openui/open-ui#1189

dbaron: *introduces issue*

dbaron: this drew objections from whatwg meeting

sarah: in favor of fieldset at least being an option, its really helpful to have a nice way to add a visible name sometimes to a group of related items

sarah: especially for checkboxes and radios

sarah: if you can do that with styles, you should be able to do it with semantic grouping

sarah: if we have an option for that it might as well be a happy path

dbaron: yeah the ability to label is something i should write in

dbaron: im a little confused about how much we want to go into this is a visible label vs just a11y tree

sarah: if you have a grouping that can have a visible label and you just want it to be a11y then you can hide with css or use aria-label

sarah: for that you need a grouping element to define the grouping semantic around those menu items

dbaron: i hadnt previously thought about using the fieldset to group non checkbox or radio items but that sounds reasonable

sarah: we have use cases for that

lwarlow: +1 to sticking with the container element. like you say we can have the discussion about fieldset vs a new element. i think that fieldset makes sense

<bkardell> +1 to type being evil

lwarlow: i think if we dont want the containing element, the argument for doing option 3 with type in name is fairly weak. type attributes are a bad design, people dont like input, and the name attr specifically it makes sense for inputs in a form because of form submission, but it has no extra meaning here, so containing element makes sense. if we

dont do a containing element, then i think new tag names for each role is good

lwarlow: focusing on containing element or attributes is probably enough to move the conversation forwards. if we decide to go with the attribute approach, then we can decide on the specifics

dbaron: im trying to push naming stuff out of the stage 2 discussion.

gregwhitworth: +1 the containing element. the thing to watch out for, which doesnt impact stage 3 or 4, i do like the design of elements that match the roles, since i think thats the path html should go

gregwhitworth: the other question is, why are we introducing checkable instead of just doing check?

dbaron: on the fieldset?

gregwhitworth: either. i can follow up offline in the github issue

gregwhitworth: grouping container totally 100% on board. i dont want us to box ourselves in where we want a radiogroup element but then thats fieldset + radio

gregwhitworth: im concerned this may have ripple effects down the road

dbaron: checkable right now is to distinguish fieldsets that make radios vs checkboxes

dbaron: as sarah points out we would have omitting that creates neither, its just menuitems in a labeled group

lwarlow: in this case new elements for the roles isnt great. largely i agree, but if you create a different element for a radio vs checkbox, then you can mix and match them and then the browser has to decide what its going to do. but if you have a containing element that says which one it is, then the browser can force it to be one or the other,

and you cant do the bad authoring practice

<bkardell> solid argument

lwarlow: if you go with aria roles and js then you can do what you want

lwarlow: its forcing you into the nice path. so i think in that case it makes sense to not do the separate elements

gregwhitworth: my caveat was outside of menu elements

<bkardell> resolved

dbaron: i dont know that i need a resolution, other than maybe i should document the rationales for the grouping elemnet approach

gregwhitworth: we have your back

lwarlow: should we resolve on using fieldset for non checkable?

dbaron: yeah i think that makes sense

dbaron: it indeed isnt in the current proposal

<dbaron> Proposed 1: David to document rationales for fieldset approach in explainer

<bkardell> +1

<dbaron> Proposed 2: Also allow <fieldset> as a grouping element for non-radio/checkbox menuitems.

<lwarlow> +1

<lwarlow> +2

<sbender> +1

<bkardell> +1 (both)

<sarah> +12

<jarhar> +1 +2

<bkardell> +21 even

<bkardell> Resolveds

RESOLUTION: David to document rationales for fieldset approach in explainer

RESOLUTION: Also allow <fieldset> as a grouping element for non-radio/checkbox menuitems.

<keithamus> github-bot, take up openui/open-ui#1220

[command invokers] scroll command

<github-bot> OK, I'll post this discussion to openui/open-ui#1220

flackr: i believe we have an implementation in chrome. i forget who was going to write a spec for it. i think we should be able to move forward with it

keithamus: should we close this one if youre taking it to whatwg? is there a whatwg issue? is it worth us closing this one now?

flackr: i dont recall if there is an issue yet

<bkardell> maybe whatwg and whatnot... .why not

keithamus: im going to close this and say we are tracking it in whatwg

<keithamus> github-bot, take up openui/open-ui#1227

How should `interestfor` work on a disabled button

<github-bot> OK, I'll post this discussion to openui/open-ui#1227

bkardell: it seems like recent discussion agrees with what we said

bkardell: lukes proposal is reasonable

keithamus: the big problem with disabled buttons is theyre not focusable

keithamus: unless we can force them to be focusable via interestfor, the only reasonable choice is to make it not work

lwarlow: some other discussions with toolbars and menu items, a concept of a soft disabled. it seemed like the conclusion there is disabled is disabled, and if we want soft disabled then we should add a new attr for that

lwarlow: if we have that where its aria-disabled but focusable then it should work. in the case that its disabled, then it just shouldnt work. if you need the explanation, then the button shouldnt be disabled

keithamus: lets make a proposed resolution then

<keithamus> PROPOSED RESOLUTION: `interestfor` should not work for `disabled` buttons

<dbaron> FWIW in openui/open-ui#1274 (comment) the only platform I found that does soft disabling of menuitems was Windows. (Not a minor platform, though!)

vmpstr: my understanding is that the interest button is not focusable due to the ability for the ua to indicate interest in another way

vmpstr: are we setting up a way for the button to not be focusable and theres also an interest button?

lwarlow: thats what im saying you wouldnt do. you can generate an interest button for a disabled button

vmpstr: so if its disabled then it hides the interest button?

lwarlow: yes

lwarlow: if you have an <a> element without an href, then its not focusable then it doesnt partake in interest stuff

<bkardell> We should do two resolutions here

lwarlow: if it generates an interest button then thats a browser bug

keithamus: so it will change layout if its disabled?

keithamus: its much less common to change the href attribute - there are lots of forms which will toggle disabled based on whether its valid

keithamus: if this now creates a weird flashing of layout, that could be confusing

lwarlow: maybe we gneerate the thing but it doesnt do anything? we could give it disabled styles. imo we should just get rid of the thing

sarah: my expectation is similar to the last person who commented. i would expect it to still render but not do anything

sarah: when ive created the manual equivalent thats what it does, its still generated but doesnt do anything anymore

sarah: children of disabled controls dont go away, they just stop doing things

bkardell: it does seem valuable in recommending that they be distinct visually, but there are lots of ways you could imagine doing that. you could make it continue to reserve space and gray it out so that its obviously disabled

bkardell: it would make sense to break this into two resolution

<keithamus> PROPOSED RESOLUTION: Interestfor should not work on disabled elements, with some kind of UA styling tbd.

<bkardell> +1 to the first resolution

<bkardell> +1

<sarah> what I said is also just my gut feeling, I could be convinced otherwise

<sarah> by people who have thought more about this :D

lwarlow: the styling question depends on the opt in vs opt out question which i dont think is answered

lwarlow: i cant get interest button to show up currently so i cant test it

lwarlow: i would imagine that currently it hides the interest button

keithamus: are we going back to the first proposed resolution that it shouldnt work on disabled elements or should we think more about the ua styling

lwarlow: maybe proposed resolution that it doesnt work on disabled elements and then action to figure out what that means

<bkardell> +1 for assigning things to mason :)

<keithamus> PROPOSED RESOLUTION: Interestfor should not work on disabled elements. Further exploration on what we do about the ::interest-button pseudo; UA styles or do not generate.

<bkardell> +1

<sbender> +1

<lwarlow> +1

<sarah> +1

RESOLUTION: Interestfor should not work on disabled elements. Further exploration on what we do about the ::interest-button pseudo; UA styles or do not generate.

<keithamus> github-bot, take up openui/open-ui#1465

Keyboard behaviour of custom select options

<github-bot> OK, I'll post this discussion to openui/open-ui#1465

<keithamus> jarhar: there are two issues here; 1. should chrome implement the safari behavior, where right = down and left = up. 2nd issue is how do you make this work nicely in grid.

<keithamus> jarhar: should have double checked safari's right=down/left=up

<keithamus> jarhar: maybe we can resolve on that?

<dbaron> My inclination is that maybe you want the default behavior of the different arrows to depend on direction and writing-mode

<keithamus> jarhar: appearance:auto right and left don't do anything... though maybe in vertical writing mode?

<keithamus> lwarlow: safari behavior is right same as down and left is up; essentially focusgroup where axes is both

<keithamus> lwarlow: on topic of focusgroup, ??? listbox constrained. This is a listbox.

<keithamus> lwarlow: ultimately i think keyboard stuff is impl defined, so fine either way

<keithamus> lwarlow: we need to solve problem of what you do when styles change layout; need to solve for focusgroup and select. A larger thing to do rather than take an action on select specifically.

<keithamus> lwarlow: from my perspective: chromium doesn't need to change immediately, more research on 2d focusgroup and grid focusgroup

<keithamus> lwarlow: maybe a way to apply that to select. Maybe solution is to add focusgroup to select.

<Jacques> I'll be spending time on 2D focusgroup immenently.

<keithamus> gregwhitworth: agree with your proposal, completely disagree on listbox being vertical

<keithamus> gregwhitworth: I like the examples posted - like a game, but select, but horitonzal, left/right makes complete sense to do

<keithamus> gregwhitworth: simple, all directions make sense.

<keithamus> gregwhitworth: figuring it out holistically, with a bunch of demos

<keithamus> dbaron: one other thought: intuition for i18n is possibly that- ignoring potentially dealing with 2d better- it makes sense to have defaults for which arrows do what be a function of writing mode, e.g horitontal rtl vs vertical rl

<keithamus> lwarlow: something we want to check with i18n people. Discussed for focusgroup, visual doesn't mean it impacts directionality of keys

<keithamus> dbaron: seems most weird for vertical rl

<keithamus> dbaron: select by default starts at right with each option to left, seems weird for left and right to do the opposite of that.

<keithamus> jarhar: left goes forwards and right goes backwards - so different between writing modes, want to post on the issue to highlight exact browser differences

RESOLUTION: there will be no resolution

<bkardell> good job everybody

<bkardell> 🍻

<keithamus> Zakim: end meeting