17:38:27 RRSAgent has joined #openui 17:38:31 logging to https://www.w3.org/2023/08/31-openui-irc 17:56:58 philippgfeller has joined #openui 17:59:58 ScottKellum has joined #openui 18:00:34 I'm having jitsi issues :/ 18:00:40 Zakim, start meeting 18:00:40 RRSAgent, make logs Public 18:00:42 please title this meeting ("meeting: ..."), gregwhitworth 18:00:42 jarhar has joined #openui 18:00:47 meeting: Open UI Telecon 18:02:44 masonf has joined #openui 18:02:54 bkardell_ has joined #openui 18:03:55 present+ 18:04:41 greg, join with the non-moderated link 18:04:44 Luke has joined #openui 18:05:25 present+ 18:05:34 github-bot, take up https://github.com/whatwg/html/issues/9625 18:05:34 masonf, I can't comment on that github issue because it's not in a repository I'm allowed to comment on, which are: openui/open-ui. 18:06:06 Topic: Invoker Buttons - allowing popover/dialog and more to be invoked without JS 18:06:39 masonf: this is imo a nice proposal that tries to generalize the feature that we added for popover invokers to all kinds of things 18:06:52 masonf: there is a new set of attributes called "invokertarget", just like "popovertarget" 18:07:01 masonf: and then there is an invoker action, you can read the way that works 18:07:12 We didn't really discuss much TPAC wise other than an FYI that it's happening 18:07:19 ? 18:07:22 q? 18:07:28 q+ 18:07:42 masonf: you can use these together to invoke from a button to various things, including popovers, dialogs, details/summary, if the target is a video element you could target the play/pause button and even custom actions for custom elements or, its very extensible 18:08:00 masonf: it also has a provision for interest target, which distinguishes between clicking the target. interest target means when you hover over this element you could have a different behavior happen 18:08:11 masonf: you could have a button which when clicked opens something, but when hovered opens a toolip 18:08:13 *tooltip 18:08:18 ntim has joined #openui 18:08:20 present+ 18:08:29 masonf: in terms of open questions, there are a number about the details and bikeshedding 18:08:39 q? 18:08:40 masonf: i wanted to bring it up and see if people thought it was a good or bad idea, what problems, etc 18:08:42 Present+ 18:08:48 present+ 18:08:56 present+ 18:08:59 lukew: this is a great idea. there was a previous proposal that keith wrote for dialogs 18:09:03 present+ 18:09:21 lukew: my two concerns are the dialog one specifically was talking about modal dialogs, and it would be interesting to see how this works in that regard. i imagine it would call showmodal on it 18:09:50 lukew: accessibility, how it works with aria making that automatic. something like a popover or dialog could be handled automatically, but if its calling an invoke event it would need some extra thought 18:09:56 lukew: overall this is a great idea 18:10:28 masonf: there is an invoker action which you can set for a dialog, you can say invoker action = show or invoker action = modal to differentiate between them. we would have to define a default, which i think should be a modal dialog 18:10:36 masonf: your points about ax are great, we need to think about that 18:10:43 q? 18:10:46 masonf: for popover and dialog there are easy answers, for the rest im not sure 18:10:47 ack Luke 18:11:01 masonf: we dont have comments from whatwg 18:11:09 q+ 18:11:13 masonf: there have been a few comments generally. its been confusing because there are a couple proposals 18:11:24 masonf: this is the first one where the questions that i had were answered, so i think its a complete proposal 18:11:34 masonf: my next thing would be to ask for explicit comments from whatwg folks 18:11:59 q+ 18:12:08 masonf: it is important: popover=hint is something that i and we have been working on and hover triggering - the fact that this also has interest based triggering, i would like to prioritize this so that we dont duplicate it in the new popover stuff 18:12:18 masonf: funnel new usage to the new thing and try to deprecate popovertarget 18:12:18 If an element also has both a popovertarget and invokertarget attribute, then popovertarget must be ignored: invokertarget takes precedence. An element with both interesttarget and popovertarget is valid and both actions will work. 18:12:55 gregw: what you said is my concern. this is a generalized popover - popover was too scoped, and should popovertarget not exist and invokertarget... 18:13:06 masonf: if we could go back in time, yeah. this is how things evolve though 18:13:29 gregw: to your point, this feels very similar to some of the flex stuff. im probably further along in the path, im thinking how can we come back and make invokertarget work 18:13:38 masonf: the idea is that invokertarget can do all the things that popovertarget can do 18:13:47 masonf: you do have to figure out what happens when you use them both on accident 18:13:50 q? 18:13:59 ack greg 18:14:03 gregw: the expectation is that this is generalized and we are going to discourage the popover version in the future. i like how its generalized 18:14:22 gregw: they say its for buttons and input type buttons, but is this also for anchors? +1 to the explainer i like it 18:14:40 masonf: anchors is an open question, has another issue. related to hover, but invoker im not sure, we should still navigate? 18:14:41 ack Luke 18:15:11 lukew: it would be useful to get a strong definition of interest, so that we dont go down the path of hover and other stuff 18:15:33 lukew: i think this in an ideal world would have been what popovertarget would have started with, but were not too far down to replace it yet 18:15:48 masonf: i agree, that is something weve been talking about, it needs to be more than hover, there are still some questions that are open 18:15:50 +1, I actually think if we fast follow enough we could deprecate and remove popover 18:16:04 masonf: if you want hover to work but youve provided your own keyboard behavior, how does that work? this is not a done deal, especially on the interest things 18:16:18 lukew: i wonder if we could get invoker in and then interest could be a followup thing 18:16:24 lukew: especially since popovertarget already exists 18:16:27 masonf: yeah, that would de-risk this 18:16:28 q? 18:17:00 masonf: no resolutions here, just wanted to talk about it, we have some questions to answer. but the group is generally positive? 18:17:15 *group generally nodded, so answer is yes* 18:17:37 github-bot, take up https://github.com/openui/open-ui/issues/786 18:17:37 Topic: [exclusive accordion] exclusively non-exclusive... 18:17:37 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/786. 18:18:35 dbaron: we talked about two weeks ago about doing a developer poll about this question about whether exlusive accordions should always enforce exlclusivity when open attribute is present or when calling from script 18:19:10 dbaron: i originally specced it as saying it doesn't strictly enforce it, so if you write details open on two details elements that are in the same group, then they are both open until user opens a third one, then it would close those two. brian was not happy about that, thought it was bad DX 18:19:16 dbaron: i thought there was pluses and minuses 18:19:22 dbaron: various technical reasons i did this 18:19:35 dbaron: some of which people have pointed out solutions to, some of which are still up in the air 18:19:45 dbaron: we did a developer poll which i largely wrote the wording of but brian provided feedback 18:20:04 dbaron: the results were not overwhelming. we got a lot of responses, the results are i would say probably 60% to 40% in favor of brians view 18:20:31 dbaron: the voting results were slightly in favor of brians view, but there were a decent number of folks who thought the dev ergonomics were better one way or the other 18:20:33 Option 1: 55, Option 2: 86 18:20:40 q? 18:20:58 dbaron: i was hoping to say, "anne pointed out this thing in this other attribute that already works that way" and we could just do what brian prefers, but im not ready to say that 18:21:07 dbaron: i prototyped it, and it doesnt work 18:21:17 dbaron: i still have to figure out why the other thing i based it on works fine and this one doesnt 18:21:31 dbaron: hopefully soon ill be able to say im comfortable going either way 18:21:47 q+ 18:21:48 dbaron: im curious if other folks think that 60/40 dev poll if we are comfortable doing that if its more complex, should we do it that way 18:21:56 q? 18:21:59 ack bkardell_ 18:22:09 bkardell: i would ask and make sure that you think that nothing i said in the thread sort of poisoned the poll 18:22:11 dbaron: i dont think so 18:22:41 bkardell: a few people did change their mind after they heard other details. some people read it specifically as i give you markup from the server and this is the only time that happens, but in reality there are multiple circumstances where that happens 18:23:01 61% for option 2 18:23:10 bkardell: 55 votes for option 1, and 86 for option 2, i think if anything its probably more slanted than it appears 18:23:40 bkardell: im surprised by that, i should be surprised since every poll we do is like this, this is the most lobsided weve ever seen 18:23:50 Isn't it 68 votes option 1? 18:23:54 bkardell: it makes me feel better that there are other people who think that option 1 is viable 18:23:59 q? 18:24:00 q+ 18:24:12 bkardell: im not going to specifically object to option 1, i just dont think that its a very good solution 18:24:30 bkardell: we are already inching out such a specific definition of it, with that 30 lines of js you can do more than this 18:24:42 bkardell: i was worried that devs were gonna complain about this and say that you can do better with a little js 18:24:48 bkardell: it seems like people wouldnt do that 18:24:57 bkardell: im glad we had the conversation and i dont think we have definitive results 18:25:05 bkardell: it does lean towards the way i see it 18:25:08 bkardell: its up to the group really 18:25:09 q? 18:25:10 q+ 18:25:15 ack masonf 18:25:27 masonf: my sense is that most of the objection to option 2 was that there are strange technical things you have to do to get that to work 18:25:47 masonf: there are cases where you remove attrs that are in the html. there are proposals that make that work. id say wait until david is done to verify that it is implemetnable 18:25:57 masonf: option 1 would be great, but if it isn't possible to do then we cant do it 18:26:09 masonf: whatever somebody did to publicize this, it was the most voted poll ever in openui 18:26:11 q? 18:26:15 ack dbaron 18:26:39 dbaron: when i wrote the poll i left option 2 vague in terms of behavior to enforce exlclusivity 18:27:12 q+ to clarify something quickly 18:27:23 dbaron: i got feedback about progressive rendering. interaction with progressive rendering and technical issue both point in the direction that is both better and more likely to be implemnetnable is that if youre inserting something into the docuemtn and theres already an open one, then you remove the attribute from the new one because you dont want to close one thats already open 18:27:38 dbaron: also better from the tech perspective because youre messing with attributes on the thing being inserted which is a little less weird 18:27:45 dbaron: i posted it on mastodon and it got a lot of boosts 18:27:54 dbaron: i was worried because the number of boosts and votes were about the same 18:27:59 dbaron: it was less than 2:1 ratio 18:28:12 dbaron: which meant that some of the people boosting werent voting 18:28:39 ack bkardell_ 18:28:39 bkardell_, you wanted to clarify something quickly 18:28:54 bkardell: i noted this carefully in the original issue, i just want to reiterate that all of the complexity of why it is this way is specifically unique to details 18:29:05 bkardell: we are starting from the most problematic place, an alternative is to just not fire events 18:29:13 dbaron: there are a few other elements, dialog does it state the same way 18:29:22 ack ntim 18:29:36 ntim: doesnt option 1 provide more flexibility for developers? if they want to do not exclusive initially, then enforce it on user action? 18:29:41 masonf: that was one of the points made for option 1 18:29:44 q? 18:29:49 q+ 18:29:56 (got my network disconnected, and then easily able to rejoin) 18:29:59 masonf: the counterpoint is that its funny, its funny capability. you get to do whatever you like in html, but then when you click it goes away. im paraphrasing though 18:30:00 ack bkardell_ 18:30:11 bkardell: my pushback is that there are a lot of accordions, point me to one that did that 18:30:27 we have ressearch for a reason, right? 18:30:43 dbaron: with what i was proposing before, my approach was to say this is an authoring error and one that should be shown by the validator if its in the markup just to make it clear that its not the intent of the feature to do that sort of thing 18:30:52 masonf: so its technically outlawed before, just possible 18:30:58 q? 18:31:04 (maybe "just" was the wrong word there, multiple reasons...) 18:31:20 good clarification dbaron :) 18:31:24 masonf: no resolution here, just make sure option 2 is implementable and come back to discuss again? 18:31:40 github-bot, take up https://github.com/openui/open-ui/issues/758 18:31:40 Topic: Design Systems page probably could use updates 18:31:40 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/758. 18:32:21 bkardell: i dont know that we have addressed this, but the first components grid was created a long time ago, and design system we refer to shifts in time 18:32:46 bkardell: we have been around long enough that some have come around, others have come defunct. microsofts ones are confusing because there was ones that were supplanting each other 18:32:59 bkardell: i think it could use some help, there are links there to stardust ui and fabric 18:33:23 q+ 18:33:38 gregw: what is our goal for this issue? to your point its ever evolving, i just dont know what to do with this issue. do we want to update the charter that every 6 months we will clean? what is the... 18:33:50 masonf: +1 to the resolution that we should not let things linger until they are stale 18:33:59 bkardell: even annually, there should be some plan going forward 18:34:17 gregw: can we resolve on an annual review? i just want to go land these PRs, i appreciate them taking this time to open and fix them 18:34:24 Proposed resolution: there should be an annual review of design systems page. 18:34:27 gregw: ill ping ??? and see if they have time to automate them 18:34:42 gregw: for github avatars, i throw a calendar in and say go update them 18:34:49 gregw: if we could automate that would be good 18:34:56 I'll ping @andrico 18:35:09 bkardell: when you do a research, its nice if theres a list like heres a bunch of them. for tabs we did more than are in here, i dont know if thats ok or encouraged 18:35:21 gregw: i encourage if its not in the table dont assume it doesnt exist 18:35:38 gregw: that design table is a launching point and we should keep it up 18:35:45 RESOLVED: there should be an annual review of design systems page. 18:35:48 +1 18:35:53 gregw: there should be an annual review of the design systems page. i will open a calendar item on myself once these 3 land 18:35:54 +1 18:36:03 gregw: i will also ping andrico and see if we can automate so it can be monthly 18:36:28 I think there might be another one that "went private" and you can't get to their system anymore - tho that might have just been a tabs one 18:36:52 +1 18:36:56 +2 even 18:37:41 I will be out the following week too probaly as I will be on holiday 18:38:05 github-bot, take up https://github.com/openui/open-ui/issues/802 18:38:06 Topic: Errors for form related controls 18:38:06 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/802. 18:38:22 q- 18:38:39 gregw: selectlist is closer so i need to raise it to make sure we dont lose it. errors are usually associated, required or pattern 18:38:49 gregw: its related to invokertarget thing, a solution could fall out of that 18:38:59 gregw: if im looking at how a lot of design systems do that, its already right within the element 18:39:08 gregw: i dont think thats how were going to do selectlist 18:39:25 gregw: most of the browsers do it in the shadowdom? someone can correct me. it may vary by control 18:39:43 gregw: to look at salesforce. success is you get a toolbar across the top, but if theres errors its inline with the input 18:39:47 q+ 18:40:03 gregw: i just want to raise the scenario that people are going to want to style these things that get rendered, and we dont have control over that, and to devs thats part of that anatomy 18:40:11 gregw: i want to make these 3 look like my design system 18:40:40 gregw: i dont have a solution, but one thing i would want to avoid is just have it auto stamp out everywhere, so i dont have to by default change that specifc elements failure text i can, but in most scenarios i wouldnt want to 18:41:06 q+ 18:41:09 gregw: its an interesting problem space before we cement selectlist, it would be cool to go back and say we know for sure we dont want it in the anatomy. if we do, then we need to figure it out now 18:41:15 masonf: we dont want it in the anatomy 18:41:36 masonf: implementation wise, in all browsers they are not in the renderer, its in the browser, separate OS window, not stylable to the control 18:41:43 q+ 18:41:49 masonf: not that this is ideal, there is a request in whatwg to be able to style those validation bubbles 18:41:50 ack masonf 18:42:01 masonf: i would like to separate that out so that we solve that independently and separately from selectlist 18:42:14 masonf: i dont think that the solution for that requires you to incorporate it into the anatomy 18:42:28 masonf: we are proposing a way to style that without saying its really part of the element 18:42:36 masonf: i dont think we should block on this and i dont think we should include it in the anatomy 18:42:39 ack Luke 18:43:07 lukew: just from an ideas point of view, likewise with the tooltip, these to me seem like popovers. obviously right now they are native ui, but they seem like a thing that just an error popover, but it would be separate from the selectlist 18:43:15 lukew: you could invoke one popover from each input 18:43:27 lukew: likewise with tooltips, it would be a popover of interest rather one that invokes 18:43:36 gregw: what was in my brain was having a definition in the dom and its declarative 18:43:55 gregw: its part of the anatomy, but now its not part of the anatomy. i appreciate the tooltip one, pseudo elements are good but they are limited 18:44:14 gregw: just a square thats flat, i want to replace the content at that point, not just change colors and border 18:44:23 gregw: certain tonality that i use for them, and the localization 18:44:36 gregw: im intrigued that the invoker paradigm, because its accomplishing the same goal 18:44:50 gregw: on submit, invoker wont work, and ironically this is when that all takes place 18:45:16 gregw: we just need to do the magic behind the scenes, if this type of pattern invoker whatever element, some magical thing, the browser knows to go find that, if theres a global one or an idref 18:45:32 gregw: i got what i wanted out of this, which is dont block selectlist, it should be generalized and not part of the anatomy 18:45:39 masonf: are you ok with a resolution of that? 18:45:46 gregw: yes, give me a solution but not in the selectlist anatomy 18:45:47 Proposed resolution: this is a good problem to solve, but it's independent of the 18:45:53 q? 18:45:59 +1 18:46:07 ack greg 18:46:10 +1 18:46:29 bkardell: it was more than selectlist, as a rule, but thats fine 18:46:36 RESOLVED: this is a good problem to solve, but it's independent of the . We should solve this generally. 18:46:57 github-bot, take up https://github.com/openui/open-ui/issues/815 18:46:57 Topic: [popover] Can we add hover-triggering to anchor (``) elements? 18:46:57 OK, I'll post this discussion to https://github.com/openui/open-ui/issues/815. 18:47:22 masonf: this ties into the invokertarget thing, question applies to both 18:47:34 masonf: whether or not we use the old style popover attributes to do this or the new thing 18:47:37 masonf: what about anchor elements? 18:47:56 masonf: if you hover a link, it shows you a thing, and if you click it it navigates you 18:47:59 q+ 18:48:02 masonf: should that be allowed? are there issues with that? 18:48:21 q? 18:48:21 masonf: should it be possible to use click invoker targets? should you be able to take over an anchor and make it do something else when you click? 18:48:36 lukew: i think it would be good to allow ??? 18:48:37 q+ 18:48:58 lukew: we need to be careful where the browser already shows ui. if you hover a link it shows a preview of the address at the bottom 18:49:10 lukew: could you spoof the url bar to make them think theres a link that takes them somewhere 18:49:21 lukew: you could already hijack and it make it navigate elsewhere though... 18:49:34 lukew: hijacking a link element to do something else, not the best idea, but sort of thing people do 18:49:48 lukew: if we allow hovering but not click, people would say why? does it make sense to prevent this 18:50:01 lukew: im a bit torn on preventing it, but i guess AX needs to come into the decision 18:50:04 github-bot has joined #openui 18:50:19 masonf: browsers sometimes show on top of everything, you cannot spoof that obviously 18:50:33 masonf: you couldnt spoof it where it currently lives. you could show your own in the page to confuse the user 18:50:38 q? 18:50:40 ack Luke 18:50:44 ack bkarde 18:50:55 bkardell: i think that there were some examples of this that email do at some point, would these be covered with the popover 18:51:01 bkardell: im supportive of adding them to anchor 18:51:13 bkardell: i think in the examples i showed you, i included examples where its not even in anchor 18:51:25 bkardell: i dont know, then maybe those are better off as popups 18:51:40 bkardell: if you have an article and it has words in there that have definitions, that you could just hover over, and see the word defined 18:51:58 bkardell: i think in some of those cases there had been a paradigm where they generated a bigger target next to the word 18:52:08 bkardell: so that you had something to interact with that didnt pull double duty like that 18:52:15 bkardell: on mobile, you got a thing you can touch 18:52:28 bkardell: im wondering if maybe theres something to consider in that. how would you handle those cases? would they be links? 18:52:38 bkardell: could they be more general than anchors 18:52:59 masonf: the reason we limited popover triggering to buttons is that example you have: just the word isnt focusbale, so someone with a keyboard cant get there 18:53:13 bkardell: same with you have a div, div overflows, how are you going to scroll that? browsers could solve that 18:53:42 q+ 18:53:48 masonf: i would envision the developer does that. the developer has to provide something thats a button or link. if the browser has to do it then it gets tricky 18:53:48 ack Luke 18:54:06 lukew: interesttarget could mean some sort of behavior where its focusable, where it isnt by default 18:54:26 lukew: you could have a definition html element or how you would go about doing that, then the browser would go that needs to be focusable because its interest 18:54:50 q? 18:54:52 masonf: the other way to go is to make the thing focusable always, but that runs into issues. good suggestion 18:55:11 bkardell: could have it be focusable as long as its shown, but not show in some circumstances 18:55:19 bkardell: an additional element, a pseudo element 18:55:31 masonf: then that psuedo element can be on any element, and is only generated when theres interst 18:56:03 bkardell: maybe it should be an anchor. i just want to think about the pattern and the problem. there are lots of things like this. there are words, buttons you get this attached to, a target next to the button that explains what the button is going to do, a question mark next to it 18:56:28 bkardell: question mark next to form fields. what are these? are they all hints? whats the definition of a hint? and how do you make sure theyre usable on touch devices 18:56:38 bkardell: can it handle these use cases? what does that look like? is anchor not enough 18:56:45 bkardell: im supportive of what youre doing 18:57:06 masonf: the question mark is done to make sure its interactable, you want to allow keyboard users a way - so theres another button. but both of those i think are buttoins 18:57:21 masonf: i didnt hear a resolution here, other than yeah thats a good problem we should solve it 18:57:26 +1 18:57:38 masonf: besides anchors, should we add other things? that could be a resolution i heard some consensus 18:57:48 lukew: i think it was more of a how than a should we 18:57:52 lukew: i am generally supportive 18:57:55 Proposed resolution: it seems like a good idea to add this capability to anchors. Questions about "how" remain. 18:58:02 q+ 18:58:05 +1 18:58:06 +1 18:58:19 q1 18:58:24 RESOLVED: it seems like a good idea to add this capability to anchors. Questions about "how" remain. 18:58:25 ++ 19:00:39 title: foo 19:00:44 topic: foo 19:01:03 I have made the request to generate https://www.w3.org/2023/08/31-openui-minutes.html dbaron 19:02:16 s/topic:foo// 19:02:18 s/title:foo// 19:02:26 I have made the request to generate https://www.w3.org/2023/08/31-openui-minutes.html dbaron 19:02:54 Present+ jarhar 19:02:57 Present+ lukew 19:03:01 Present+ xiaochengh 19:03:31 ScribeNick: jarhar 19:03:56 As of this point the attendees have been bkardell_, ScottKellum, ntim, dbaron, gregwhitworth, masonf, +, jarhar, lukew, xiaochengh 19:03:58 RRSAgent, please draft minutes 19:03:59 I have made the request to generate https://www.w3.org/2023/08/31-openui-minutes.html Zakim 19:04:05 I am happy to have been of service, dbaron; please remember to excuse RRSAgent. Goodbye 19:04:05 Zakim has left #openui 19:04:31 s/topic: foo// 19:04:36 s/title: foo// 19:04:49 s/s\/topic:foo\/\/// 19:04:54 s/s\/title:foo\/\// 19:05:02 I have made the request to generate https://www.w3.org/2023/08/31-openui-minutes.html dbaron 19:09:41 github-bot has joined #openui