Re: [w3ctag/design-reviews] The `interesttarget` attribute (Issue #1058)

mfreed7 left a comment (w3ctag/design-reviews#1058)

> _Currently_ it's discrete. There is nothing preventing us from defining an attribute that makes it not-discrete.

I guess it'd need to be two more attributes, like `commandforinterest=showPopover` and `commandforloseinterest=hidePopover`. Feels like a lot to add to the existing `commandfor` just for the sake of combining similar things.

> > * As described below, due to the statefulness, the set of automatic actions for `interestfor` is more limited.
> 
> I'm not sure that this kind of micromanagement of author goals is desirable. Authors can already do these things via JS, this is just a nicer declarative API. I don't think it's productive to decide in advance that because we can't think of use cases in the moment, these features need to be artificially restricted. If the concern is abuse, there are already mechanisms in the web platform to prevent that for JS as well (e.g. requiring activation, etc).

There's a natural tension here though, between total flexibility on the one hand, and footguns on the other. I'd love to support actual, common use cases. But I don't want to build the most general API possible, if that means that most developers will encounter footguns in most cases.

> For example, media playback was discussed in that thread as "ripe for abuse" for interest invokers. And yet, playing muted videos on hover is an incredibly common way for video sites to show short previews, a use that I don't think constitutes abuse? In fact, this is actually a great case for why these attributes should be available on more element types eventually.

This is a great point - video starting and stopping is also a naturally "paired" operation. Perhaps there's a "v2" expansion for a few select other elements that have similar start/stop or open/close type operations. That's a super natural expansion of this API:

```html
<a href=# interesttarget=foo>Hover me to play video</a>
<video id=foo></video>
```


> To me, this seems like another issue with this design. Requiring authors to remember which separate sets of elements support `commandfor`, `interestfor` and `popovertarget` seems like a learnability disaster. Especially once these sets start being expanded, which is bound to happen. Custom elements for one are an obvious candidate.
> 
> It seems like a more coherent and learnable design is to have a single set of attributes to specifying the commands with one of them one to specify _how_ the command is activated. This would also allow a lot more flexibility down the line (e.g. what if we later want to allow invoking commands via a keyboard shortcut? Or some other mechanism? Will we invent a fourth API?). It would also open up possibilities for nice sensible defaults, e.g. defaulting to different default `commandaction` values for different types of commands or depending on the target (see below).

Keyboard shortcuts would almost surely be document-level, not element-specific, right? Hitting a hotkey only when focused on an element feels broken. So that's likely a separate API anyway. 

Again, I'm not sure the flexibility is warranted. I.e. **all three current popover-related values** for `command` don't work with hover-triggering. So would you also invent a new value like "auto" for `command` that is useful for hover-triggering? From a developer point of view, this seems cumbersome:

```
<a href=# commandfor=popover commandinvokedby=hover command=auto>This feels long</a>
<a href=# interestfor=popover>This feels natural</a>
<a href=# interestfor=popover commandfor=something_else>This is also possible</a>
```

> I had assumed that when the target popover is `popover=hint`, `popovertarget` and friends automatically use interest-based interactions to open it. Are there use cases of `popover=hint` popovers that still need to open on click? 

It's really the other way around. There are examples of `popover=auto` (such as menus) that would be great to use with hover-triggering. It's a bit odd to be looking for more general solutions, but suggest removing flexibility from the hover-triggering part, limiting it only to tooltips via `popover=hint`.


> FWIW one reason I can see for _having_ separate attributes is having _both_ types of commands co-existing on the same element. E.g. a button that displays a popover on hover/focus, but opens a dialog on click.

Yep, that's definitely a use case. A button that does something when clicked, but has a hover-triggered tooltip that tells you what that thing is. This is almost universal behavior on toolbars, for example.


> But then again, if all use cases for this are popovers, this seems like something that should be done through the Popover API? The fact that the Popover API still requires JS for some of its primary use cases is a failing of the Popover API that should be addressed, not plastered over with more API surface.

I guess I agree that it's a failing of the web platform, but I'd say `interestfor` is the platform solution for that failing. Again, to implement a tooltip, you previously needed a lot of JS. The `popover=hint` API removed a bunch of that JS: the code to do light dismiss. The `interestfor` API removes the rest: it replaces the hover triggering JS code.


> > I agree with this - it'd be good to deprecate `popovertarget*`.
> 
> +1 to that, for the very same reasons that make me lean against having separate `interestfor` attributes, with the caveat above: that it seems common to need popovers and commands on the same element so perhaps `popovertarget` could accommodate that.

For the reasons already discussed, I do firmly believe two attributes are needed. You seem to be advocating for re-using `popovertarget`, but that's specific to popovers. It seems like the two should be `commandfor` and `interestfor`, as the more general two APIs for click- and hover-triggering actions. And we should deprecate `popovertarget`.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1058#issuecomment-3114317753
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1058/3114317753@github.com>