Meeting minutes
<gregwhitworth> github-bot, take up openui/
[interest invokers] How to define/control the action on "losing interest"
<github-bot> OK, I'll post this discussion to https://
masonf: I have been picking up the interesttarget thing. First thing that came up… trying to normalise how gaining and losing interest work
masonf: I added a comment with background to the issue… will give a summary
masonf: we wanted to build this like command and commandfor
masonf: eg what is the target and what will i do on it
masonf: but I don't know if it makes sense to do it similarly on interesttarget, because not sure if you'd have multiple actions. And you could get into weird situations
masonf: eg if you have a toggle for a popover that toggles on hover, it could get really weird
masonf: command/commandfor, the one in the explainer, has things like showing fullscreen elements or playing videos, seems actively bad to allow hover to do those things
masonf: so my Q: what elements should we support and do we need an interestaction, eg a way to specify the action.
masonf: personally I think we don't need interestaction, just have a default one. We should definitely support popovers as a target, and probably dialogs, can talk about that… but maybe not others.
masonf: and then we could think about custom actions too
lwarlow: I don't think we need actions, I think I proposed and added, it seemed logical at the time, but don't think we need it
lwarlow: if it's something we want to add in the future, we could… I think we probably only would support popover, don't even think it makes sense to support dialog, certainly not modal dialogs, and given that non-modal dialogs would ideally be built with popover anyway…
lwarlow: re the custom thing… we can do two things: no events and you do all of it custom… or we always fire the event, popover does a thing and no other element does
lwarlow: I'm in two minds about that
lwarlow: concern I have is… the command attr in the future…we can't change later / retroactively add if not preventdefaulting
lwarlow: I don't think in a year we would decide to randomly open, say, <details>…
nmn: question: the interest is opening up a hover card type of UI… we just said we would only open popovers not dialogs, I think it makes sense… but what sort of roles will the UI itself have?
nmn: something I'm currently building switches between a dialog and a tooltip depending on whether you trigger with a hover as a temporary workaround
masonf: to clarify the question is hovering to open a modal dialog
nmn: would agree with that we should not have fine grained control over type of trigger, would be hard to translate across platforms
flackr: +1 to firing an event with this for developers to handle
flackr: they can decide best how to handle it
<lwarlow> +1 to that I was going to mention that and forgot to
flackr: @@@
sarah7: when something opens via hover, role at time of hover isn't super hover important as when you're on the trigger you wouldn't really have a way to get to the role
scott: I mentioned in the issue, modal dialog doesn't seem a useful addition in this case…
scott: would have no problem with non-modal dialogs, eg that's how people can create hovercards, they could be popovers or not
scott: if I hover over something by accident and the whole page becomes inert… could be really annoying… I'm thinking people who use voice access and don't control the mouse, they might be accidentally hovering by scroling
masonf: conclusions that I heard: we don't need interestaction.
masonf: also hearing we need events so that they can be handled
masonf: re future things like the open attribute… that probably makes sense to support, but it's a future thing so no backward compat issue
masonf: and I heard modal dialogs are out, I'm good with that too because of some use cases including the one scott mentioned
<masonf> Proposed resolution: remove `interestaction` attribute, only support popovers and not modal dialogs, always fire the interest/loseinterest events at all events, and support the openable attribute in the future.
<lwarlow> +1
flackr: some of the input modalities require us to know that it accepts intersts
flackr: need to handle if something accepts interest
masonf: yes
flackr: so we can't fire the interest events at all elements
flackr: we have to say I want to add an eventlistener for interest to say it is a thing that receives interst
masonf: we were thinking of adding something like an outline to elements with an interesttarget attr
<masonf> Proposed resolution: remove `interestaction` attribute, only support popovers with default actions (e.g. not modal dialogs), always fire the interest/loseinterest events at all elements, and support the openable attribute in the future.
masonf: through the UA stylesheet, with :focus-visible
<lwarlow> +1
<hdv> +1
<flackr> +1
<keithamus> +1
lwarlow: one thing to keep in mind… previously, we resolved that interesttarget can work on buttons, HTML links, area and, I think, SVG links… currently popover is defined in HTML, when speccing this, the SVG is going to be interesting?
masonf: agree, have been implementing for element
RESOLUTION: remove `interestaction` attribute, only support popovers with default actions (e.g. not modal dialogs), always fire the interest/loseinterest events at all elements, and support the openable attribute in the future.