Meeting minutes
<gregwhitworth> I'm having jitsi issues :/
<masonf> greg, join with the non-moderated link
<masonf> github-bot, take up whatwg/
<github-bot> 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.
Invoker Buttons - allowing popover/dialog and more to be invoked without JS
masonf: this is imo a nice proposal that tries to generalize the feature that we added for popover invokers to all kinds of things
masonf: there is a new set of attributes called "invokertarget", just like "popovertarget"
masonf: and then there is an invoker action, you can read the way that works
<Luke> We didn't really discuss much TPAC wise other than an FYI that it's happening
<Luke> ?
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
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
masonf: you could have a button which when clicked opens something, but when hovered opens a toolip
*tooltip
masonf: in terms of open questions, there are a number about the details and bikeshedding
masonf: i wanted to bring it up and see if people thought it was a good or bad idea, what problems, etc
lukew: this is a great idea. there was a previous proposal that keith wrote for dialogs
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
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
lukew: overall this is a great idea
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
masonf: your points about ax are great, we need to think about that
masonf: for popover and dialog there are easy answers, for the rest im not sure
masonf: we dont have comments from whatwg
masonf: there have been a few comments generally. its been confusing because there are a couple proposals
masonf: this is the first one where the questions that i had were answered, so i think its a complete proposal
masonf: my next thing would be to ask for explicit comments from whatwg folks
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
masonf: funnel new usage to the new thing and try to deprecate popovertarget
<gregwhitworth> 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.
gregw: what you said is my concern. this is a generalized popover - popover was too scoped, and should popovertarget not exist and invokertarget...
masonf: if we could go back in time, yeah. this is how things evolve though
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
masonf: the idea is that invokertarget can do all the things that popovertarget can do
masonf: you do have to figure out what happens when you use them both on accident
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
gregw: they say its for buttons and input type buttons, but is this also for anchors? +1 to the explainer i like it
masonf: anchors is an open question, has another issue. related to hover, but invoker im not sure, we should still navigate?
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
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
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
<gregwhitworth> +1, I actually think if we fast follow enough we could deprecate and remove popover
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
lukew: i wonder if we could get invoker in and then interest could be a followup thing
lukew: especially since popovertarget already exists
masonf: yeah, that would de-risk this
masonf: no resolutions here, just wanted to talk about it, we have some questions to answer. but the group is generally positive?
*group generally nodded, so answer is yes*
<masonf> github-bot, take up openui/
[exclusive accordion] exclusively non-exclusive...
<github-bot> OK, I'll post this discussion to https://
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
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
dbaron: i thought there was pluses and minuses
dbaron: various technical reasons i did this
dbaron: some of which people have pointed out solutions to, some of which are still up in the air
dbaron: we did a developer poll which i largely wrote the wording of but brian provided feedback
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
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
<masonf> Option 1: 55, Option 2: 86
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
dbaron: i prototyped it, and it doesnt work
dbaron: i still have to figure out why the other thing i based it on works fine and this one doesnt
dbaron: hopefully soon ill be able to say im comfortable going either way
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
bkardell: i would ask and make sure that you think that nothing i said in the thread sort of poisoned the poll
dbaron: i dont think so
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
<masonf> 61% for option 2
bkardell: 55 votes for option 1, and 86 for option 2, i think if anything its probably more slanted than it appears
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
<Luke> Isn't it 68 votes option 1?
bkardell: it makes me feel better that there are other people who think that option 1 is viable
bkardell: im not going to specifically object to option 1, i just dont think that its a very good solution
bkardell: we are already inching out such a specific definition of it, with that 30 lines of js you can do more than this
bkardell: i was worried that devs were gonna complain about this and say that you can do better with a little js
bkardell: it seems like people wouldnt do that
bkardell: im glad we had the conversation and i dont think we have definitive results
bkardell: it does lean towards the way i see it
bkardell: its up to the group really
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
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
masonf: option 1 would be great, but if it isn't possible to do then we cant do it
masonf: whatever somebody did to publicize this, it was the most voted poll ever in openui
dbaron: when i wrote the poll i left option 2 vague in terms of behavior to enforce exlclusivity
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
dbaron: also better from the tech perspective because youre messing with attributes on the thing being inserted which is a little less weird
dbaron: i posted it on mastodon and it got a lot of boosts
dbaron: i was worried because the number of boosts and votes were about the same
dbaron: it was less than 2:1 ratio
dbaron: which meant that some of the people boosting werent voting
<Zakim> bkardell_, you wanted to clarify something quickly
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
bkardell: we are starting from the most problematic place, an alternative is to just not fire events
dbaron: there are a few other elements, dialog does it state the same way
ntim: doesnt option 1 provide more flexibility for developers? if they want to do not exclusive initially, then enforce it on user action?
masonf: that was one of the points made for option 1
<dbaron> (got my network disconnected, and then easily able to rejoin)
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
bkardell: my pushback is that there are a lot of accordions, point me to one that did that
<bkardell_> we have ressearch for a reason, right?
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
masonf: so its technically outlawed before, just possible
<dbaron> (maybe "just" was the wrong word there, multiple reasons...)
<bkardell_> good clarification dbaron :)
masonf: no resolution here, just make sure option 2 is implementable and come back to discuss again?
<masonf> github-bot, take up openui/
Design Systems page probably could use updates
<github-bot> OK, I'll post this discussion to https://
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
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
bkardell: i think it could use some help, there are links there to stardust ui and fabric
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...
masonf: +1 to the resolution that we should not let things linger until they are stale
bkardell: even annually, there should be some plan going forward
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
<masonf> Proposed resolution: there should be an annual review of design systems page.
gregw: ill ping ??? and see if they have time to automate them
gregw: for github avatars, i throw a calendar in and say go update them
gregw: if we could automate that would be good
<gregwhitworth> I'll ping @andrico
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
gregw: i encourage if its not in the table dont assume it doesnt exist
gregw: that design table is a launching point and we should keep it up
RESOLUTION: there should be an annual review of design systems page.
<bkardell_> +1
gregw: there should be an annual review of the design systems page. i will open a calendar item on myself once these 3 land
<Luke> +1
gregw: i will also ping andrico and see if we can automate so it can be monthly
<bkardell_> 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
<bkardell_> +1
<bkardell_> +2 even
<bkardell_> I will be out the following week too probaly as I will be on holiday
<masonf> github-bot, take up openui/
Errors for form related controls
<github-bot> OK, I'll post this discussion to https://
gregw: selectlist is closer so i need to raise it to make sure we dont lose it. errors are usually associated, required or pattern
gregw: its related to invokertarget thing, a solution could fall out of that
gregw: if im looking at how a lot of design systems do that, its already right within the element
gregw: i dont think thats how were going to do selectlist
gregw: most of the browsers do it in the shadowdom? someone can correct me. it may vary by control
gregw: to look at salesforce. success is you get a toolbar across the top, but if theres errors its inline with the input
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
gregw: i want to make these 3 look like my design system
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
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
masonf: we dont want it in the anatomy
masonf: implementation wise, in all browsers they are not in the renderer, its in the browser, separate OS window, not stylable to the control
masonf: not that this is ideal, there is a request in whatwg to be able to style those validation bubbles
masonf: i would like to separate that out so that we solve that independently and separately from selectlist
masonf: i dont think that the solution for that requires you to incorporate it into the anatomy
masonf: we are proposing a way to style that without saying its really part of the element
masonf: i dont think we should block on this and i dont think we should include it in the anatomy
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
lukew: you could invoke one popover from each input
lukew: likewise with tooltips, it would be a popover of interest rather one that invokes
gregw: what was in my brain was having a definition in the dom and its declarative
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
gregw: just a square thats flat, i want to replace the content at that point, not just change colors and border
gregw: certain tonality that i use for them, and the localization
gregw: im intrigued that the invoker paradigm, because its accomplishing the same goal
gregw: on submit, invoker wont work, and ironically this is when that all takes place
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
gregw: i got what i wanted out of this, which is dont block selectlist, it should be generalized and not part of the anatomy
masonf: are you ok with a resolution of that?
gregw: yes, give me a solution but not in the selectlist anatomy
<masonf> Proposed resolution: this is a good problem to solve, but it's independent of the <selectlist>
<Luke> +1
<bkardell_> +1
bkardell: it was more than selectlist, as a rule, but thats fine
RESOLUTION: this is a good problem to solve, but it's independent of the <selectlist>. We should solve this generally.
<masonf> github-bot, take up openui/
[popover] Can we add hover-triggering to anchor (`<a>`) elements?
<github-bot> OK, I'll post this discussion to https://
masonf: this ties into the invokertarget thing, question applies to both
masonf: whether or not we use the old style popover attributes to do this or the new thing
masonf: what about anchor elements?
masonf: if you hover a link, it shows you a thing, and if you click it it navigates you
masonf: should that be allowed? are there issues with that?
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?
lukew: i think it would be good to allow ???
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
lukew: could you spoof the url bar to make them think theres a link that takes them somewhere
lukew: you could already hijack and it make it navigate elsewhere though...
lukew: hijacking a link element to do something else, not the best idea, but sort of thing people do
lukew: if we allow hovering but not click, people would say why? does it make sense to prevent this
lukew: im a bit torn on preventing it, but i guess AX needs to come into the decision
masonf: browsers sometimes show on top of everything, you cannot spoof that obviously
masonf: you couldnt spoof it where it currently lives. you could show your own in the page to confuse the user
bkardell: i think that there were some examples of this that email do at some point, would these be covered with the popover
bkardell: im supportive of adding them to anchor
bkardell: i think in the examples i showed you, i included examples where its not even in anchor
bkardell: i dont know, then maybe those are better off as popups
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
bkardell: i think in some of those cases there had been a paradigm where they generated a bigger target next to the word
bkardell: so that you had something to interact with that didnt pull double duty like that
bkardell: on mobile, you got a thing you can touch
bkardell: im wondering if maybe theres something to consider in that. how would you handle those cases? would they be links?
bkardell: could they be more general than anchors
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
bkardell: same with you have a div, div overflows, how are you going to scroll that? browsers could solve that
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
lukew: interesttarget could mean some sort of behavior where its focusable, where it isnt by default
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
masonf: the other way to go is to make the thing focusable always, but that runs into issues. good suggestion
bkardell: could have it be focusable as long as its shown, but not show in some circumstances
bkardell: an additional element, a pseudo element
masonf: then that psuedo element can be on any element, and is only generated when theres interst
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
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
bkardell: can it handle these use cases? what does that look like? is anchor not enough
bkardell: im supportive of what youre doing
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
masonf: i didnt hear a resolution here, other than yeah thats a good problem we should solve it
<bkardell_> +1
masonf: besides anchors, should we add other things? that could be a resolution i heard some consensus
lukew: i think it was more of a how than a should we
lukew: i am generally supportive
<masonf> Proposed resolution: it seems like a good idea to add this capability to anchors. Questions about "how" remain.
<Luke> +1
<bkardell_> +1
<bkardell_> q1
RESOLUTION: it seems like a good idea to add this capability to anchors. Questions about "how" remain.
++
<dbaron> s/topic:foo//
<dbaron> s/title:foo//
<dbaron> s/s\/topic:foo\/\///
<dbaron> s/s\/title:foo\/\//