[interest invokers] How to define/control the action on "losing interest"

[mfreed7]

Here's a basic tooltip example:

<button interesttarget=tooltip>?</button>
<div popover=hint id=tooltip>Tooltip</div>

The desired behavior, for a tooltip, is:

1. When the ? button is hovered/focused/etc for a short while ("interest"), the popover will be shown.
2. The popover will stay open as long as either the button or the popover are hovered/focused/etc.
3. When neither has been hovered/focused/etc for a short while ("interest has been lost"), the popover will be hidden.

It has been proposed, for the "invokers" proposal, to require the action (command) attribute. If that sticks, and is also required here, does that mean there will need to be two more action attributes? For example, we might need showinterestaction and loseinterestaction so that the above example becomes:

<button interesttarget=tooltip showinterestaction=showpopover loseinterestaction=hidepopover>?</button>
<div popover=hint id=tooltip>Tooltip</div>

I don't think a single value (e.g. interestaction=togglepopover) works. Because you could hover the button to show the popover, and then click outside, which will light-dismiss the popover, and then after a short while the "lose interest" event will happen, which will toggle the popover back open. Suppressing the "lose interest" event in this case seems a bit too magic.

[lukewarlow]

This came up from my limited prototyping in chromium. I don't think toggle is actually correct you want it to behave how you've described above. Now it's possible we can do a special "do the thing" for popover but more likely we should build it into the API.

[mfreed7]

Now it's possible we can do a special "do the thing" for popover but more likely we should build it into the API.

My thought was that the "auto" behavior could magically do the right thing for popovers. But if we want to have an explicit way to do the same magic (or if we're going to always require the action attribute(s)), it seems like you'd need to have two attributes, or a special value of a single attribute that implies this magic.

[css-meeting-bot]

The Open UI Community Group just discussed [interest invokers] How to define/control the action on "losing interest", and agreed to the following:

• RESOLVED: there should be a value of the interestaction attribute that means the correct behavior for popovers. They show when interest is shown, and hide when interest is lost.

The full IRC log of that discussion

<gregwhitworth> scribenick: jarhar
<jarhar> masonf: talking about the interesttarget attribute. the invoketarget attribute which is now called command, it was decided that both the target attribute and the action attr need to be specified. different from popover where you dont have to say the action
<jarhar> masonf: there is a desire for the command attribute for requiring both commandfor and commandaction
<jarhar> masonf: if we require both, funny things happen for interesttarget. interesttarget=tooltip and then when you show interest the popover is shown. while youre hovering over that it stays open. when neither is focused then the popover is hidden. two different actions have taken place from that one attribute
<jarhar> masonf: on interest the popover is shown, and on lose interest its hidden. maybe thats "toggle", but its not exactly toggle because things can get out of sync
<bkardell_> q+
<jarhar> masonf: there needs to be some magic value that describes this whole behavior
<jarhar> masonf: or that there should be two action attributes
<jarhar> masonf: there should only be one target attribute, but there might need to be separate actions for gain interest and lose interest
<gregwhitworth> ack jarhar
<keithamus> q+
<gregwhitworth> ack bkardell_
<jarhar> bkardell_: im curious. i know this was bound to happen. its a tight window of making a new proposal in response to this. theres some desire expressed to make that required. is there really agreement? i hear and have some counter thoughts on that
<jarhar> bkardell_: im not sure that we know we do want to require it. do we?
<jarhar> masonf: i agree with you, i dont want to make it required, its convenient, popovertarget is convenient and id like to keep that for command
<jarhar> masonf: where we are with standards, webkit - anne was the first to say both should be required. at the last meeting, olli also said yeah makes sense to make it required. that to me represents two implementers
<jarhar> masonf: nothing says we cant later make it implied, we can make it not required later, its not permanent, so i was inclined to go along with it
<gregwhitworth> ack keithamus
<jarhar> keithamus: im in the same position with that, i would rather see it not be required, but in the interest of shipping id like to do what the consensus is
<jarhar> keithamus: i am against the idea of discrepancy as showing and losing interest as a discrete behavior
<jarhar> keithamus: it makes things complicated and im not sure theres value. i dont know when youd want to invert the relationship, like hide the popover when you gain interest
<jarhar> keithamus: those are nonsensical values
<jarhar> keithamus: i would contest - its worthwhile exploring that one value like togglepopover - we should always try to do the sensible thing. i dont know of a case where you want to hide a popover when you gain interest
<jarhar> keithamus: the browser can gain this discretenes - they can keep the interest values discrete but not show them to the user
<jarhar> keithamus: when interest is gained the popover should be shown, and when its lost it should be hidden. when interest is lost it can be a multitude of things
<jarhar> keithamus: if you click the invoking button we can do the fixup to ??? the interest
<jarhar> keithamus: i get the sense that we can explore an option where we have interesttarget and interestaction
<masonf> q?
<masonf> q+
<gregwhitworth> ack dbaron
<jarhar> dbaron: one of the things i heard mason asking about was naming suggestions for what this thing could be thats not exactly togglepopover
<keithamus> q+
<jarhar> dbaron: if the thing is make the popover match the interest state then its not quite toggle. maybe synchronize/sync or match? i dont really like either of them but some thoughts
<jarhar> masonf: you want magic behavior - i agree that togglepopover should do exactly what it does for js but it doesn't mean we should make a new word like sync. finding a good word is tough, but a new value for this behavior seems reasonable
<jarhar> keithamus: maybe its doing mental gymnastics but i dont see it not doing what togglepopover does. togglepopover already does the - the dismissal of a popover during togglepopover still - a popover opened with togglepopover is still light dismissable, it just depends on how you frame it in terms of interest
<jarhar> keithamus: one of those can still explain the narrative of how losing interest works. either way, thats fine i can understand the hesitance for togglepopover as a name
<jarhar> keithamus: in place of toggle, why not just call it popover? interestaction=popover, that just means do the popover things
<masonf> ack mason
<masonf> ack keith
<dbaron> (or intereststate=popover)
<masonf> ack dbaron
<jarhar> dbaron: i was thinking the same as keith. maybe action isnt the right word anymore and its intereststate
<jarhar> keithamus: interestfor as the idref, and interest as the attribute, so interest=popover
<jarhar> masonf: it does feel convenient if the values are shared between command and interest. its a nice set of things and its specific to each kind of element, and feels nice to mix and match these things
<jarhar> masonf: there can be some magic behavior in deciding when to fire these events, but i would like it if once its decided that funcitoned like firing an event, which is why i like togglepopover meaning do exactly togglepopover regardless of what it means, and having a different value meaning do some magic thing. the interest event is going to have
<jarhar> some state on it for gaining or losing interest
<jarhar> masonf: that feels less magical and more easily defined
<jarhar> keithamus: the receiving element has some say in determining when interest is lost. typically thats focus but i could imagine the receiving element could have a promise or callback to say now i allow you to lose interest
<gregwhitworth> q?
<jarhar> keithamus: not suggesting that, but if we were just talking about interactive elements then it would be an easy way to describe this
<jarhar> keithamus: but if youre opening a popover without interactive elements, then we want to do cursor fixups so if your mouse moves to the invoker
<jarhar> keithamus: to me that suggests theres an extra piece here where the receiving element can hold interest
<jarhar> keithamus: are you expecting parity with commands? i dont know how that would hold
<jarhar> keithamus: i think we went through this before. theres nothing it would hold in command that has parity with interestaction
<jarhar> keithamus: we dont want to show a modal on interest, or play a video on interest
<jarhar> masonf: you might. i coudl see a play pause button, or mutes and unmutes, not a great ui but an idea
<jarhar> masonf: is interesttarget only value for popovers?
<jarhar> masonf: if thats true, then theres a dramatic simplification we can make, just do popoverinterest and drop the command stuff
<jarhar> keithamus: thats how it was originally proposed, but seemed worthwhile to customize the interest action
<jarhar> masonf: customized for popovers?
<jarhar> keithamus: other kinds of elements
<jarhar> keithamus: you could use interest for the series of buttons in a carousel type ui where focus and even hover would move to the next item in the carousel
<jarhar> keithamus: flowcharts with anchor positioning, dont want to preclude those capabilities
<jarhar> keithamus: the only concrete case seems to be popovers
<keithamus> s/concrete case/concrete case in the browser
<jarhar> masonf: i can see both sides. originally there was popovertargetaction=hover
<jarhar> masonf: general purpose api winning the day, none of these are great examples but somebody will come up with one
<bkardell_> it's different though because it's specific, right? masonf ?
<gregwhitworth> q?
<jarhar> bkardell_: popover is one very specific thing, and some of the concerns i have and have heard - a lot of this happened at a time where people couldnt pay attention to it, one of the things i was hearing was that as it gets more generic you have to think about it differently too. for popover, some of them make sense but less so as we make it generic
<jarhar> masonf: it would be bad if we made it generic and then made the core use case not work well. that should be a part of what we design
<jarhar> keithamus: the lose interest - just imagining a userland implementation, if i wanted to capture interest i could preventdefault the lose interest, could do the same fixups as the browser
<jarhar> keithamus: to me, it seems reasonable to do a fair amount of magic to make sure that the popover use case is very solid in the browser because that is the core use case
<gregwhitworth> q?
<jarhar> keithamus: if we want to make that association explicit and let the innovators of the web do stuff with it that seems fine as well
<jarhar> masonf: we have agreement ish on there should be some way to make the correct thing happen for popovers. does that sound like something we should agree on? should that be a value of the interestaction attribute that means that magic behavior?
<masonf> Proposed resolution: there should be a value of the interestaction attribute that means the correct behavior for popovers. They show when interest is shown, and hide when interest is lost.
<keithamus> +1
<dbaron> +1
<masonf> RESOLVED: there should be a value of the interestaction attribute that means the correct behavior for popovers. They show when interest is shown, and hide when interest is lost.
<bkardell_> +1
<masonf> and the value should be 'magicbehaviorforpopoversplease'
<bkardell_> could it be if there is no value?

[mfreed7]

I gave this (a lot) more thought. I'm leaning toward the conclusion that really, we don't need/want an interestaction attribute at all. The point is that "gaining" and "losing" interest are separate, yet paired, actions. That's different from command/commandfor which have a single activation point. It's possible they happen to be paired, as when command=togglePopover and the popover opens for the first click and closes for the second. But not always.

Essentially, I went through the use cases and supported values for command:

• For popovers:
  • The only "real" use case is to show the popover when the user "shows interest" and hide the popover when the user "loses interest". That's almost by definition, given the names. E.g. when would it ever make sense to show a popover when the user "loses interest" in the element?
  • There are very easy footgun situations. For example, it seems natural for the default action to be togglePopover for both gaining and losing interest. However, let's say it's <button interesttarget=popover>, and the user clicks the button. First they would have had to hover the button to click it, which will toggle the popover open. Then they click it, which light-dismisses the popover. So far, ok. But then they de-hover the button, which "loses interest" in it, which toggles the popover back open. And now the state is inverted until they repeat this process.
• For dialogs:
  • Much the same situation as popovers. Perhaps even more of a footgun, given that the dialog can be already-open via <dialog open>. More-so once dialog light dismiss lands.
  • Also similar to popover, it seems that the only real use case is to show a (modal) dialog when the user shows interest in the element, and close it when they lose interest. Perhaps one corner case might be that they don't want to close it on losing interest, which could be achieved easily by preventDefault()ing the interestlost event.
• Details/summary:
  • Again, easy footguns if we use toggle behavior, and the natural use case is to expand the details when the user shows interest.
• <input type=number>
  • The command explainer has two action types, step-up and step-down. I have no idea what the use case might be for a user hovering something that steps up/down a number input. Perhaps there is one, but it seems like a rare one, since I don't think I've ever seen such a behavior.
• Fullscreen
  • The command explainer allows actions for requesting and cancelling fullscreen on the target element. I think it might be very actively bad to support this on hover, since it side-steps user activation and seems ripe for abuse.
• Media play/pause
  • The command explainer has actions for play, pause, etc. Here also, this seems actively bad and ripe for abuse.
• Custom elements / custom event handlers
  • The command PR has the provision for a "custom command", which is a command that begins with double-dash --. That can be used by either manually-added event handlers, or custom elements that similarly watch for the command event.
  • Here, I might see a use case that would want a way to pass values to the target element. Having said that, this use case already requires Javascript, and it's no extra work to simply pass the desired action to the destination element out-of-band, in one of several ways. So it doesn't seem like a huge deal not to have access to an action.

Given the above, the conclusion I came to was that a) we don't need interestaction, and b) the default actions should all be to show/open the target on "show interest" and hide/close the target on "lose interest". I'm guessing that also makes the UA-provided a11y connections a lot easier to reason about. Note that this also aligns very well with the resolution just above, to "do the right thing for popover".

Any thoughts?

(See also, the discussion at #905.)

[lukewarlow]

Btw the intention is just to do popovers for interest, not the other actions (opening a modal dialog might be problematic for example). I guess the openable attribute might be fair game too

Though I do wonder what about custom actions? I guess the future compat issue isn't as big an issue here. Worth thinking about though.

[keithamus]

Fully supportive of not adding an interestaction or equivalent. I think there are an extremely narrow set of use cases for justifiably changing UI on interest. Showing/hiding content is effectively it. Doing anything more is likely user hostile. There's some argument for preloading, however that can be handled with JS quite simply. And just like command/commandfor there's always the possibility to write some JS to intercept the new events on the target (invokee) element, which is a nice escape-hatch.

If through the development of this feature someone finds a really compelling use case for something other than "showing/hiding" that is justified within the platform and not JS, then perhaps we can revisit.

[mfreed7]

Btw the intention is just to do popovers for interest, not the other actions (opening a modal dialog might be problematic for example). I guess the openable attribute might be fair game too.

I debated <dialog> also. But since it didn't seem outright hostile, just perhaps a bit weird, and it is supported for command/commandfor, I was leaning toward trying to keep dialog support. Thoughts?

Though I do wonder what about custom actions? I guess the future compat issue isn't as big an issue here. Worth thinking about though.

I agree future compat isn't an issue, so I'm hoping we can explore how this functionality actually gets used, and we can add back an action if needed there?

Fully supportive of not adding an interestaction or equivalent. I think there are an extremely narrow set of use cases for justifiably changing UI on interest.
If through the development of this feature someone finds a really compelling use case for something other than "showing/hiding" that is justified within the platform and not JS, then perhaps we can revisit.

Agree also. Thanks.

Let's have the discussion, but in the meantime, I'm prototyping this behavior, without interestaction.

[scottaohara]

opening a modal dialog on "interest" would definitely be problematic - if i'm understanding this. since if it's modal, then focus would need to immediately move to it. how does one lose interest in that then? would a mouse hovering outside of the dialog mean that? that's where the mouse cursor might already be. does that then create an infinite loop of the dialog opening and closing since the backdrop is covering the invoking element?

apologies if i'm completely missing something here and i've just made up a scenario that wouldn't exist?

[css-meeting-bot]

The Open UI Community Group just discussed [interest invokers] How to define/control the action on "losing interest", and agreed to the following:

• RESOLVED: 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.

The full IRC log of that discussion

<hdv> masonf: I have been picking up the interesttarget thing. First thing that came up… trying to normalise how gaining and losing interest work
<lwarlow> q+
<hdv> masonf: I added a comment with background to the issue… will give a summary
<hdv> masonf: we wanted to build this like command and commandfor
<hdv> masonf: eg what is the target and what will i do on it
<hdv> 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
<hdv> masonf: eg if you have a toggle for a popover that toggles on hover, it could get really weird
<hdv> 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
<hdv> masonf: so my Q: what elements should we support and do we need an interestaction, eg a way to specify the action.
<hdv> 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.
<hdv> masonf: and then we could think about custom actions too
<hdv> q?
<gregwhitworth> ack lwarlow
<masonf> q+ nmn
<hdv> 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
<flackr> q+
<hdv> 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…
<hdv> 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
<hdv> lwarlow: I'm in two minds about that
<hdv> lwarlow: concern I have is… the command attr in the future…we can't change later / retroactively add if not preventdefaulting
<hdv> lwarlow: I don't think in a year we would decide to randomly open, say, <details>… 
<gregwhitworth> ack nmn
<gregwhitworth> q?
<hdv> 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?
<sarah7> q+
<hdv> nmn: something I'm currently building switches between a dialog and a tooltip depending on whether you trigger with a hobver as a temporary workaround
<hdv> s/hobver/hover
<hdv> masonf: to clarify the question is hovering to open a modal dialog
<scott> q+
<hdv> nmn: would agree with that we should not have fine grained control over type of trigger, would be hard to translate across platforms
<gregwhitworth> ack flackr
<hdv> flackr: +1 to firing an event with this for developers to handle
<hdv> flackr: they can decide best how to handle it
<lwarlow> +1 to that I was going to mention that and forgot to
<gregwhitworth> ack sarah
<masonf> q+
<hdv> flackr: @@@
<gregwhitworth> ack scott
<hdv> 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
<hdv> scott: I mentioned in the issue, modal dialog doesn't seem a useful addition in this case… 
<hdv> scott: would have no problem with non-modal dialogs, eg that's how people can create hovercards, they could be popovers or not
<gregwhitworth> ack masonf
<hdv> 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
<hdv> masonf: conclusions that I heard: we don't need interestaction.
<hdv> masonf: also hearing we need events so that they can be handled
<hdv> 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
<hdv> 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> q+
<gregwhitworth> ack flackr
<hdv> flackr: some of the input modalities require us to know that it accepts intersts
<hdv> flackr: need to handle if something accepts interest
<hdv> masonf: yes
<hdv> flackr: so we can't fire the interest events at all elements
<hdv> flackr: we have to say I want to add an eventlistener for interest to say it is a thing that receives interst
<lwarlow> q+
<hdv> 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.
<hdv> masonf: through the UA stylesheet, with :focus-visible
<lwarlow> +1
<hdv> +1
<flackr> +1
<keithamus> +1
<hdv> 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?
<hdv> masonf: agree, have been implementing for element
<masonf> RESOLVED: 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.
<gregwhitworth> Zakim, end meeting