"command" and "commandfor" attributes

[keithamus]

WebKittens

@nt1m, @annevk, @rniwa

Title of the spec

HTML: command and commandfor attributes

URL to the spec

whatwg/html#9841

URL to the spec's repository

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

Issue Tracker URL

whatwg/html#9625

Explainer URL

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

TAG Design Review URL

w3ctag/design-reviews#920

Mozilla standards-positions issue URL

mozilla/standards-positions#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]

mozilla/standards-positions#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 (openui/open-ui#952 (comment)) 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]

WebKit/WebKit#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.

[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 whatwg/html#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: whatwg/html#9625 (comment).

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

[annevk]

Thanks for the nudge:

1. This is a repository to determine the position of the WebKit community on specifications and proposals. While Apple is a major contributor to WebKit, it would not be accurate to say that the positions taken on this repository constitute an official position from Apple.
2. I wonder if this should be renamed to the "command and commandfor attributes"?
3. I think we have reached the point where barring any further feedback, we should mark this as "position: positive" one week from now.