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

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


> I guess my only pushback generally is that this isn't "entirely different". It's quite parallel, on purpose, to `commandfor`, e.g. this attribute is called `interestfor`.

If having `for` in the name were enough to draw a parallel then `<label for>` is also parallel to this…


> * `commandfor` is discrete: activating the button triggers the command. `interestfor` is stateful: you can show interest, and then lose interest later, and there's a state in the middle of "having interest".

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

> * 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).

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.

Custom commands were also another use case.

> * The `commandfor` API is quite a bit more general, and can work with many kind of elements.

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. Same for `interestfor`. 

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).

> There are essentially two APIs needed to make a "tooltip". One is a behavior that keeps the tooltip popover from closing unrelated popovers - that's `popover=hint`. The other API is a way to trigger popovers via something other than a "click" - that's interest invokers.

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? If not, it seems that `popover=hint` declares the author intent sufficiently, so it shouldn't require additional signal to do what's expected. And even there are, if they are a minority, it's not a good tradeoff to require unnecessary boilerplate from 99% of use cases to accommodate the 1% edge case — just define a good default and provide ways for the edge cases to override it.

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. 

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.

> > From an author pov, it's already confusing that there is both command="show-popover" commandfor="mypopover" AND popovertarget="mypopover" popovertargetaction="show".
> 
> 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.


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

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