[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?