17:32:44 <RRSAgent> RRSAgent has joined #openui
17:32:48 <RRSAgent> logging to https://www.w3.org/2024/10/24-openui-irc
17:59:46 <gregwhitworth> Zakim, start meeting
17:59:46 <Zakim> RRSAgent, make logs Public
17:59:48 <Zakim> please title this meeting ("meeting: ..."), gregwhitworth
17:59:53 <gregwhitworth> meeting: Open UI Telecon
17:59:58 <gregwhitworth> Chair: Greg Whitworth
18:00:01 <gregwhitworth> present+
18:01:10 <brecht_dr> brecht_dr has joined #openui
18:02:10 <scott> scott has joined #openui
18:02:32 <hdv> scribenick: hdv
18:03:47 <frehner> frehner has joined #openui
18:04:07 <gregwhitworth> github-bot, take up https://github.com/openui/open-ui/issues/1114
18:04:07 <github-bot> Topic: The utility of the `popover=hint` feature
18:04:07 <github-bot> OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1114.
18:05:20 <hdv> keithamus: popover hint is a new value that will allow you to place a popover, like auto, but it won't close other autos
18:05:27 <hdv> keithamus: so it's almost like a new layer or stack
18:05:32 <hdv> keithamus: there can only be one hint open at a time
18:05:42 <hdv> keithamus: the predominant use case is to have tooltip style popovers
18:05:55 <brecht_dr> present+
18:05:55 <hdv> keithamus: like when you hover over a link or interactive control, a tooltip will open up
18:06:15 <hdv> keithamus: toasts and notifications also don't want to close other popovers
18:06:45 <brecht_dr> q+
18:06:55 <hdv> keithamus: so the discussion is … what's the utility of hint as a separate part of the platform?
18:07:18 <brecht_dr> q-
18:07:20 <hdv> gregwhitworth: I'll clear this issue
18:07:23 <hdv> gregwhitworth: as we're waiting for responses
18:07:34 <gregwhitworth> github-bot, https://github.com/openui/open-ui/issues/825
18:07:34 <github-bot> gregwhitworth, Sorry, I don't understand that command.  Try 'help'.
18:07:44 <gregwhitworth> github-bot, take up https://github.com/openui/open-ui/issues/825
18:07:44 <github-bot> Topic: select: Should `<selectedoption>` respond to mutations in the selected `<option>`
18:07:44 <github-bot> OK, I'll post this discussion to https://github.com/openui/open-ui/issues/825.
18:08:06 <dbaron> Present+
18:08:29 <hdv> JakeA: when you select an option, or the default one becomes selected, the content of the selected option is cloned and light dom inserted inside of selectedoption, which is optional
18:08:49 <hdv> JakeA: my question is… while there's content in one of the options, waht should happen if you modify one of those options
18:09:14 <hdv> JakeA: originally it would get recloned, but based on feedback from webkit, who said it was a bit weird… so next step was to do it synchronously
18:09:27 <hdv> JakeA: problem with that was… a basic modification of the dom was going to mutate many many times
18:09:45 <jarhar> jarhar has joined #openui
18:09:48 <hdv> JakeA: that's going to happen a lot more than people expect
18:10:24 <hdv> JakeA: i think the biggest problem with it is that there's no way to stop the clone or modification happening
18:10:43 <hdv> JakeA: there will be cases where people make a change to the content of the option because they want to change the content of that option
18:11:06 <hdv> JakeA: eg we don't want hover effects to be duplicated over
18:11:35 <hdv> JakeA: what makes me worried about this is that we get more and more elements that modify their own attributes… am not thrilled about it, but it seems to be the new hotness (hidden-until-found, details/summary, I think dialog does it too)
18:11:55 <hdv> JakeA: I know we can't put details inside option, but if we could it would expend in one place and also inside of the selected option
18:12:06 <hdv> JakeA: so I wondered… what do we do… I asked for developer feedback
18:12:24 <hdv> JakeA: what I heard the most… people who are using React or another framework are not going to use this
18:12:32 <masonf> masonf has joined #openui
18:12:34 <masonf> q?
18:12:50 <brecht_dr> q+
18:12:53 <masonf> q+
18:12:57 <gregwhitworth> q+
18:13:00 <hdv> JakeA: one simple thing we could do…is to say… when you select the option, it clones then, andit will never reclone unless you do it manually… and we could  potentially some easier way to do that
18:13:32 <hdv> JakeA: we already have `replaceChildren()`…the bit we're missing is `cloneChildren()`, that would provide an easy way to do it… or a method on `<selectedoption>`
18:13:45 <gregwhitworth> ack brecht_dr
18:13:53 <hdv> brecht_dr: +1 on not changing the selectedoption more than once
18:14:00 <hdv> brecht_dr: oh ja
18:14:05 <hdv> s/oh ja//
18:14:28 <gregwhitworth> q+ steveOrvell
18:14:47 <gregwhitworth> ack masonf
18:15:21 <hdv> masonf: my concern was React, but think most people in React would use a portal or something and do it themselves, but in React it would be easy anyway to do it
18:15:36 <hdv> masonf: I had been thinking about a JS API on the select element that would sync the options
18:15:46 <hdv> masonf: you brought up clonechildren or a method on the selectedoption element
18:15:49 <gregwhitworth> q+ sarah
18:15:54 <hdv> masonf: they sound fine to me too
18:15:55 <gregwhitworth> ack gregwhitworth
18:15:56 <gregwhitworth> q+
18:16:19 <hdv> masonf: there are two things that cause the clone… the user or when it is originally parsed
18:16:45 <hdv> JakeA: the use case is, you've got an app that renders the custom select, then in the use effect it is going to get the real option and call setOptions
18:17:20 <hdv> JakeA: in that case selectedoption would still display 'loading' as React is still cloning… to get that faulty case I actually had to play around with it a bit… and in some cases eslint would scream at me too
18:18:17 <hdv> JakeA: @@@,  I know Anne isn't a fan of this,  but script element, style element already do this
18:18:19 <gregwhitworth> ack steveOrvell
18:18:47 <hdv> steveOrvell: today, the non custom select behaviour, if you modify selected option, it will synchronously update the selected option
18:18:55 <hdv> JakeA: how is it observably synchronous?
18:19:05 <hdv> steveOrvell: you can look at the offset width
18:19:10 <hdv> JakeA: of course
18:19:48 <hdv> steveOrvell: another point is re a11y: there are many ways to mess up the a11y of the custom select… the goal of Open UI is to not make things that make it easy to mess up accessibility.
18:20:14 <hdv> steveOrvell: the thing that is announced is the actual selected option , so anything you do visually would cause a discrepancy between what's visual and what's the accessible name
18:20:38 <hdv> JakeA: that's an important detail we need to make sure
18:20:45 <scott> q+
18:20:55 <hdv> masonf: what you just said Steve is a bug, what's there visual should be reflected in a11y tree, I'll make sure that gets fixed
18:20:58 <gregwhitworth> ack sarah
18:21:12 <hdv> sarah: for a11y I would prefer it to not change automatically… 
18:21:48 <hdv> sarah: if you change the value that the keyboard focus is on, the 'screenreader cursor' would be pulled back to that. It treats the active descendant as @@@2
18:22:20 <hdv> sarah: but in this case focus seems to be actually on the button not the options, in which case it would not be a problem, as the screenreader user would get an equivalent experience
18:23:12 <hdv> sarah: also, if somebody is mutating the contents of the option element… they're obviously using script for this, it is trivial to manage what's displayed without using selectedoption … so in this case the dev likely has some kind of render function and we don;'t worry about handling that as much in selectedoption
18:23:15 <hdv> JakeA: seems reasonable
18:23:47 <hdv> JakeA: if the dev has chosen to not use selectedoption but they choose to put something in, screenreader users should see that. But if they are using selectedoption … if they choose to show/hide parts of the tree, it's important that screenreader users see that
18:23:57 <hdv> sarah: yes. Also screenreader users see one thing at the time
18:24:09 <hdv> sarah: at each point it doesn't matter if the selectedoption and option content are equivaelnt
18:24:15 <hdv> s/equivaelt/equivalent
18:24:47 <hdv> JakeA: somebody asked on HackerNews if they wanted different content in the option and selectedoption… I answered you would probably do it manually
18:25:01 <hdv> sarah: in that case it would work because display:none affects the acc tree
18:25:14 <hdv> JakeA: but my understanding is in current implementation it is broken
18:25:19 <hdv> masonf: currently is broken, we'll fix it
18:25:36 <hdv>  s/currently is/yes, it is currently
18:26:06 <hdv> gregwhitworth: I'm confused on what the actual problem is when I select again?
18:26:12 <hdv> masonf: no if the user did it it would clone twice
18:26:35 <hdv> JakeA: this particular user wanted instead of cloning the option that there is a …
18:26:48 <hdv> gregwhitworth: oh I didn't mean that user, I mean the general issue here
18:27:15 <hdv> JakeA: if we clone the DOM whenever anything changes, we'll get a load of clones, if it is asynchronously, and authors might not want that reflection
18:27:37 <hdv> masonf: we'll clone for the change 'user clicks', but the issue JakeA is talking about is when the author does some kind of modification via script
18:27:54 <gregwhitworth> ack gregwhitworth
18:27:56 <hdv> JakeA: it clones whenever the option that is selected changes
18:28:04 <keithamus> q+ steve
18:28:11 <gregwhitworth> ack scott
18:28:15 <hdv> scott: some of what I was going to say was brought up
18:28:37 <hdv> scott: I see people asking similar things re modifying options or changing the content of the selected option after the fact…
18:29:07 <masonf> q+
18:29:11 <gregwhitworth> q+
18:29:17 <hdv> scott: people want to do complex stuff
18:29:33 <hdv> scott: people could mock around in the past, as steve says, but with this custom select it is much easier to make this a broken experience
18:29:48 <sorvell> sorvell has joined #openui
18:29:57 <gregwhitworth> ack steve
18:29:58 <hdv> scott: re the bug to file I'm not sure if there's a clear answer to what value should be returned or announced
18:31:00 <hdv> sorvell: to go fruther down the rabbit hole… if you're modifying the DOM inside the `<selectedoption>` via script, we can say, that's bad, don't do it  … is that confusing? (1) if we really didn't want it to happen, is there a way for us to say it cannot be modified? maybe we can tell people? (2) are we potentially limiting cool interactive patterns?
18:31:18 <hdv> sorvell: the cloning behaviour means you should not mess with this stuff
18:31:43 <sarah> sarah has joined #openui
18:31:47 <hdv> JakeA: if you say the behaviour is it clones… it's quite simple, there's; an event when this changes
18:31:56 <hdv> JakeA: you can do it via CSS so why not via the DOM
18:32:09 <gregwhitworth> ack masonf
18:32:40 <hdv> masonf: since we're defining the behaviour… it's fine if you modify the contents of selectedoption, but you know it will be blown away when someone changes the option. Am afraid of inventing some kind of unmodifyable thing
18:32:51 <sarah> q+
18:32:56 <scott> q+
18:32:58 <hdv> masonf: current behaviour is to clone the children, we should probably also clone the attrs or maybe the whole option… we should probably think about that at least
18:33:10 <JakeA> q+
18:33:53 <hdv> masonf: there's some kind of algo of what happens when it changes, the author should be able to access that exact algorithm or evnet
18:33:56 <hdv> s/evnet/event
18:34:38 <hdv> gregwhitworth: we brought up what to clone, eg styles and everything… so should we be cloning the attributes? maybe if you narrow it down to specific attributes, it would become somewhat weird DX. I think we said not to do attrs because the style attribute would cause weird edge cases
18:35:23 <hdv> gregwhitworth: we're not changing how the tree is constructed, more naming… how are we breaking accessibility?
18:35:31 <gregwhitworth> ack gregwhitworth
18:36:29 <hdv> sarah: re cloning attributes… my immediate reaction is 'oh god no', the content of the thing is the value of the select not the name , if we clone an aria label of an option onto the button of the select, we've wiped out the name of the button, and then is someone uses aria-checked instead of aria-selected and that gets cloned… could be a very bad idea for anything that can affect semantics
18:36:42 <keithamus> q+ steve
18:36:51 <jarhar> proposed resolution: dont observe mutations in option elements. only clone into selectedoption during parsing and when a new option becomes selected
18:36:54 <hdv> ack sarah
18:36:56 <gregwhitworth> ack sarah
18:37:10 <masonf> q+
18:37:19 <gregwhitworth> ack scott
18:37:28 <hdv> scott: to allude to the codepen I've shared… what happens is that the aria label on the option is return as the value… which is not… there are going to be use cases where we'll absolutely want that
18:37:55 <hdv> scott: should we reflect all the attributes on the selectedoption for instance, I'd say no… right now, anything you put on the button or selected option is going to be ignored, it's not where the values are computed from
18:38:16 <hdv> scott: selectedoption… I'm really starting to think we should treat it like slot… I think we shouldn't compute the value from that
18:38:29 <hdv> scott: because then the selectedoption could be modified in other ways
18:39:19 <gregwhitworth> ack JakeA
18:39:34 <hdv> JakeA: would putting a div with aria-label inside of the option, would that avoid the problem when cloned into selectedoption?
18:39:59 <hdv> scott: this is another area we should align on what the expected behaviour should be… eg a div is not supposed to be named at all in the aria spec
18:40:23 <hdv> scott: as long as the option returns its value which is the same as its name, arguably that should become a returned value
18:41:04 <hdv> scott: if it matches the visible text that's up to the developer, sometimes you might not, in the currency picker that Una made there was some good reasons to purposefully pick what's the acc name, to avoid the £ sign getting read out twice
18:41:11 <jarhar> proposed resolution: dont observe mutations in option elements. only clone into selectedoption during parsing and when a new option becomes selected
18:41:14 <hdv> s/twice/many times
18:41:38 <gregwhitworth> ack steve
18:42:19 <hdv> sorvell: people say different things about accessibility… previously we talked about what's in the option should be announced the same… and others say it should not be the same
18:42:43 <hdv> gregwhitworth: if somebody sets a thing to display:none in CSS… that affects acc tree too
18:42:56 <hdv> gregwhitworth: when I select an option, focus goes back to the outer button, correct?
18:42:57 <hdv> masonf: correct
18:43:22 <hdv> keithamus: we're in unchartered territory, could go either way
18:43:29 <jarhar> proposed resolution: dont observe mutations in option elements. only clone into selectedoption during parsing and when a new option becomes selected
18:43:33 <keithamus> q+
18:43:46 <hdv> masonf: these are all great issues, we need to nail down what the a11y behaviour is, though I think that's not what we're resolving here
18:43:49 <gregwhitworth> ack keithamus
18:43:50 <masonf> q?
18:43:55 <gregwhitworth> ack masonf
18:44:41 <hdv> keithamus: to +1 what masonf's says… the concern in the issue is what is the DX, because there are timing issues, it doesn't really affect the observable thing for the user?
18:45:16 <jarhar> proposed resolution: dont observe mutations in option elements. only clone into selectedoption during parsing and when a new option becomes selected
18:45:17 <hdv> keithamus: re the original question: should the option's contents clone into the selectedoption on the activation of the option, that seems like a reasonable thing to me
18:45:50 <hdv> sorvell: the ability to put the same DOM into multiple places … this could result in weird things we should account for, it gives a lot of responsibility to folks customising their selects
18:46:28 <hdv> sorvell: you could put iframes in etc… this is an advanced use case and it can only go so far, but we want to try to make the default behaviour coudl
18:46:33 <hdv> s/coudl/good
18:46:49 <hdv> masonf: agreed with that… we're opening up great power here and that comes with great responsibility
18:47:14 <jarhar> proposed resolution: dont observe mutations in option elements. only clone into selectedoption during parsing and when a new option becomes selected
18:47:34 <keithamus> +1
18:47:36 <hdv> masonf: am on the queue to say: I would like to withdraw my proposal to @@@3 and still keep my proposal to add some kind of  'synchronise selected option' method
18:47:38 <JakeA> +1
18:47:47 <hdv> +1
18:47:49 <brecht_dr7> brecht_dr7 has joined #openui
18:47:51 <sorvell> +1
18:48:21 <brecht_dr7> present+
18:48:23 <brecht_dr7> +1
18:48:27 <sarah> +1
18:48:30 <jarhar> RESOLVED: dont observe mutations in option elements. only clone into selectedoption during parsing and when a new option becomes selected
18:48:39 <brecht_dr7> (on another name, irc did something strange, no with nr 7)
18:48:45 <keithamus> q+
18:49:33 <hdv> masonf: is #825 a v2 thing?
18:49:49 <gregwhitworth> ack keithamus
18:50:03 <hdv> masonf: I would like a JS method that does exactly what the browser does when someone selects an option
18:50:06 <hdv> keithamus: I agree with that
18:50:25 <hdv> keithamus: and also… in multiple selects the options are an array, there's something you'll have to do there anyway
18:50:32 <hdv> keithamus: probably something to resolve there
18:50:47 <hdv> JakeA:  like the proposal, what the method name is etc is up for grabs
18:51:14 <hdv> sorvell: I wanted to zero in on one thing Jake said… when cloning occurs, we won't rely on an event?
18:51:28 <hdv> JakeA: I think that was a misunderstanding of what gregwhitworth was saying… he said when there is an event when does it occur?
18:51:44 <hdv> gregwhitworth: let's resolve on the spirit, then the spec text
18:52:07 <hdv> JakeA: eg if you change checked attr on a checkbox you don't get an event either
18:52:46 <hdv> JakeA: can't remember what the programmatic ways are to make changes… eg if you set selectedindex, that is 1, to 1, would that reclone or not, because you set it to the same?
18:52:55 <hdv> sorvell: are we ok with the developer being unable to respond to that?
18:53:03 <hdv> JakeA: you could put a mutationobserver on the selected option
18:53:44 <hdv> sarah: are you saying… if you have one set of options rendered, when user clicks on the same index but it is the same option it would not fire a change event?
18:53:52 <hdv> JakeA: I don't have an answer, would be something we'd need to decide
18:54:18 <hdv> masonf: even if you don't mutate but the user clicks the same option that's already selected, feels to me it should still clone
18:54:34 <hdv> jakea: selectedindex = selectedindex  gives you that clone operation
18:55:04 <gregwhitworth> github-bot, take up https://github.com/openui/open-ui/issues/1114
18:55:04 <github-bot> Topic: The utility of the `popover=hint` feature
18:55:04 <github-bot> OK, I'll post this discussion to https://github.com/openui/open-ui/issues/1114.
18:55:15 <brecht_dr7> q+
18:55:38 <hdv> masonf: my feeling is popover=hint is going to be useful together with other things and on its own
18:55:55 <JakeA> q+
18:56:02 <hdv> masonf: is popover=hint useful on itsown even if you have to do the JS yourself
18:56:12 <hdv> s/yourself/yourself?
18:56:15 <gregwhitworth> ack brecht_dr7
18:56:18 <gregwhitworth> ack brecht_dr
18:56:45 <hdv> brecht_dr7: I think it's fairly useful even without interest, I see examplewhere you could have a popover inside of a popover… could have, like, a toggletip situation, like a question mark icon
18:56:53 <sarah> q+
18:57:02 <hdv> brecht_dr7: those are things that could work… even if it's not on hover or focus style… popover=hint could still be useful to force close other hints
18:57:24 <gregwhitworth> ack JakeA
18:57:43 <hdv> JakeA: if I'm understanding the issue correctly… with popover=hint the popovers are part of a different group than others… would it make sense to have popovergroups so that you could group your poopvers in general?
18:57:47 <keithamus> q+
18:57:54 <hdv> masonf: it's already a bit confusing to explain the 'two stacks of popovers'
18:57:54 <scott> scott has joined #openui
18:57:58 <scott> q+
18:58:04 <hdv> masonf: hints are subordinate to the others
18:58:08 <keithamus> q-
18:58:17 <hdv> masonf: if you're defining n groups, it will be a bit funny
18:58:28 <hdv> masonf: think zindex
18:58:42 <gregwhitworth> ack sarah
18:58:57 <hdv> sarah: the library I work on, we have codes to do essentially this
18:59:30 <hdv> sarah: the code to handle 'only one at a time top layer tooltips': as good as we can do, but you can throw in iframes etc… it gets really difficult … so to have the browser solve the 'one at a time' kind of thing would be very useful to us
18:59:49 <hdv> sarah: would help us get rid of a bunch of hacky code
19:00:04 <hdv> masonf: it's not straightforward to put this into spec and into code, so would echo that
19:00:06 <JakeA> I need to switch to another meeting. Thank you all!
19:00:13 <gregwhitworth> ack scott
19:00:18 <hdv> s/that/sarah's points
19:00:26 <hdv> scott: wanted to echo support for popover=hint… for the tooltip case specifically
19:00:50 <hdv> scott: I would probably rather have a tooltip element rather than this… because the other use cases seem more like popover=manual for me
19:01:04 <hdv> keithamus: but you would lose out on light dismiss which is a pain to reimplement
19:01:11 <hdv> scott: I'm thinking about things like toasts
19:01:33 <hdv> keithamus: but you probably want a close watcher… which is easy ish to do but not as easy as getting it for me
19:01:36 <hdv> s/me/free
19:01:52 <hdv> scott: either way I want to support popover=hint, agree with sarah, doing this yourself is difficult
19:02:35 <hdv> keithamus: yes, agreed it is great as a separate thing, popover=manual alone is not enough
19:02:56 <hdv> RRSAgent, make minutes please
19:02:58 <RRSAgent> I have made the request to generate https://www.w3.org/2024/10/24-openui-minutes.html hdv
19:03:05 <hdv> Zakim, make minutes please
19:03:05 <Zakim> I don't understand 'make minutes', hdv