- From: Mason Freed <notifications@github.com>
- Date: Wed, 23 Jul 2025 10:44:17 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1058/3109548119@github.com>
mfreed7 left a comment (w3ctag/design-reviews#1058) https://github.com/openui/open-ui/issues/1064 > My main worry when seeing this API is that it's generally an antipattern to introduce entirely different primitives for accomplishing related goals and is often an overfitting smell. We already have the Command Invokers API and the Popover API. Do we really need an entirely separate API for this? From the outside, it feels like something that should be doable via one of them, by tweaking an attribute. 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`. But it's important to remember that while similar and related, the behavior of these two APIs is different in some important ways: - `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". - As described below, due to the statefulness, the set of automatic actions for `interestfor` is more limited. The `commandfor` API is quite a bit more general, and can work with many kind of elements. > If it can't be, perhaps the solution is to improve them, so that they are more generalizable. E.g. most use cases are some sort of popover/tooltip. > @mfreed7 in the CSS WG meeting today you mentioned an OpenUI discussion where this was discussed and it was decided that there were good reasons for it to be distinct from these existing APIs. I think it would be helpful if you could link to it? Yes, much of this was discussed at length in https://github.com/openui/open-ui/issues/1064 (in particular, see this comment https://github.com/openui/open-ui/issues/1064#issuecomment-2581511411). > @mfreed7 you mentioned that popover=hint cannot be used for this purpose and actually are unusable today without JS. This sounds like perhaps something to fix in the Popover API rather than pile more API surface on top of it? I think this is just a misunderstanding of the APIs here. 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. > 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*`. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1058#issuecomment-3109548119 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1058/3109548119@github.com>
Received on Wednesday, 23 July 2025 17:44:21 UTC