Invokers proposal

[keithamus]

WebKittens

@nt1m, @annevk, @rniwa

Title of the spec

Invokers

URL to the spec

https://github.com/whatwg/html/pull/9841

URL to the spec's repository

https://github.com/openui/open-ui

Issue Tracker URL

https://github.com/whatwg/html/issues/9625

Explainer URL

https://open-ui.org/components/invokers.explainer/

TAG Design Review URL

https://github.com/w3ctag/design-reviews/issues/920

Mozilla standards-positions issue URL

https://github.com/mozilla/standards-positions/issues/902

WebKit Bugzilla URL

https://bugs.webkit.org/show_bug.cgi?id=262840

Radar URL

rdar://116960300

Description

Please can I get a standards position on the commandfor/command/CommandEvent part of the Invokers proposal.

[lukewarlow]

https://github.com/mozilla/standards-positions/issues/902 Mozilla Position request

[keithamus]

I2P Chrome and is in Chrome Canary behind the Experimental Web Platform Features flag.

[MrBrain295]

mozilla/standards-positions#902 Mozilla Position request

This is now officially positive from Mozilla.

[lukewarlow]

Just as an fyi OpenUI have agreed (https://github.com/openui/open-ui/issues/952#issuecomment-1834461595) to an initial scope for invokers of just popover and dialog actions, along with custom actions.

So the extra proposed actions such as media controls and fullscreen aren't intended to be part of the initial proposal to html.

Hopefully this helps the WebKit team come to a conclusion on the concept of invokers and the concrete actions for popover and dialog without the more contentious additions holding it back.

[keithamus]

https://github.com/WebKit/WebKit/pull/18794 the PR for testing this feature in WebKit has been merged.

[keithamus]

Following from @lukewarlow's comments, I'd like to reiterate that the invokers explainer is now scoped down to just popover & dialog defaults initially. The spec also reflects the defaults for these two.

[nt1m]

I think @annevk / @othermaciej had thoughts on the naming / design of the feature.

[lukewarlow]

Coming back to this are there any thoughts that the WebKit team would like to share on how this can be improved to gain their support. I think the proposal and spec PR are in a fairly good state but we're obviously open to any and all feedback.

@annevk / @othermaciej did you still have feedback on the design that hasn't already been shared?

[annevk]

Discussing this with colleagues we have these concerns:

1. We don't think click needs a new name. In the past there was an attempt to introduce a DOMAction event to replace click with a similar motivation and at the time we instead decided that a click is instead generic and also started triggering it upon keyboard input, for instance. I did see there was a FAQ entry for this, but I don't think that adequately considered the long history click has had within the web platform as a generic term indicating some action is to be triggered.
2. There is a worry this might get complex real fast as there are numerous things you won't be able to do and the more you attempt to address those the more you end up reinventing JavaScript. For instance, the toggle button examples are not really compelling. You don't want your button to say "Show/Hide" or "Play/Pause". Instead its label should be the opposite of the state of the control it manipulates. However, we don't have HTML toggle buttons and adding them as well as such a reflective feature would be quite the undertaking.

1 is probably the more significant concern of the two. 2 can be addressed by knowing when to stop.

[lukewarlow]

One key difference between click and invoke is that invoke is fired on the target NOT the trigger. So one benefit is it flips the status quo allowing you to colocate logic with a target element. Because of this it doesn't seek to replace click.

Wrt to 2 thats definitely a concern we've floated a number of ideas, mostly as a thought on what it could be used for, it doesn't necessarily mean they should. Custom actions exist specifically so that we can point users to them.

[annevk]

Right, that works well though with clicktarget and clickaction.

[o-t-w]

Semantically that seems odd. The popover or dialog are not the target of clicks.

[annevk]

How are they not the target of a click on the button?

[lukewarlow]

Semantically the click is on the button, clicktarget feels to me likes it's forwarding the click elsewhere, which it's not doing, it's responding to the click by doing something ("invoking" but we can bikeshed another name) to another element.

I misunderstood originally what you meant, the concern is more about the name than the concept.

Probably better to continue the naming discussion on https://github.com/whatwg/html/issues/9625 so we can keep this less noisy, and get more input from a wider array of people.

[keithamus]

I've added some extra words in the explainer which hopefully provide more justification around the choices made. See https://open-ui.org/components/invokers.explainer/#why-the-name-invoke-why-not-click

[mfreed7]

I agree that clicktarget sounds confusing. For the two cases being proposed, popover and dialog, in neither case are you "clicking" on the popover or dialog. You're opening or closing them, but you're never clicking on them or activating them, etc. I think it might be confusing that popover.onclick=something won't fire when <button clicktarget=popover> is clicked.

[annevk]

As requested: https://github.com/whatwg/html/issues/9625#issuecomment-2115718679.

[keithamus]

Given the discussions around recent semantic & naming changes have settled, I wonder if Apple's position has moved closer to one of support? Would we be able to get an official position from Apple on this feature-set?