open-ui
open-ui copied to clipboard
[invokers] bikeshed the attribute names.
I’ve had a couple of mentions on social media, about bikeshedding the invoketarget and invokeaction names. Rather than keep that discourse on those social media platforms I thought I’d bring it here to be discussed.
This post talks about using for= instead of invoketarget=.
This post talks about using target= instead of invoketarget= and action= instead of invokeaction=.
I have reservations for both but to promote good critical discourse I thought I’d share so we have a canonical place to discuss the colour of this bikeshed.
I'm against using for or target because it precludes multiple types of targets on one element. If you want interesttarget AND invoketarget together you need the specificity.
formaction for example is formaction NOT just action. It's only action when used on the form element itself (where the context is well known).
https://x.com/Keithamus/status/1791565930528440514
https://indieweb.social/@keithamus/112458309173840363
I ran a couple of polls to try and gather some off-the-cuff opinions. Especailly WRT https://github.com/whatwg/html/issues/9625#issuecomment-2115718679.
Opinion poll!
You have a
Here are the results:
| Mastodon | Totals | ||
|---|---|---|---|
<button clickaction=open |
131 (29.4%) | 26 (17%) | 157 (26.3%) |
<button invokeaction=open |
123 (27.6%) | 64 (42%) | 187 (31.3%) |
<button command=open |
103 (23.1%) | 40 (26%) | 143 (24%) |
| Other (comment ideas) | 88 (19.8%) | 22 (14%) | 110 (18.4%) |
| Totals | 445 | 152 | 597 |
Twitter's results we quite close, but clickaction was the most popular. On Mastodon invokeaction was a very clear winner over the others. In total, this means invokeaction was the most popular, with roughyl 1/3rd the votes.
Here are some notes on the commentary:
Some notes on the discussions & results:
-
Many comments mentioned
clickactionis confusing with regard to input:-
“clickaction” isn’t really right (it’s not always a click, and the click event would be called something different if named today)
-
Is click action only invoked when clicking or can the keyboard invoke it too?
-
Command is independent of input device (which I hope the code is, too). So is invoke but it feels harder to read and more passive.
-
It should not be click because the action might not be a click (ie mobile, keyboard, etc.).
-
Click seems too specific
-
oh no invoke and click are tied.
-
I don’t think click is right because it could be actions other than a click. I think invoke is probably the best option.
-
Click is non-semantic if invoking the action can be done by focus+enter or anything else.
-
Not everyone uses a mouse to activate a button so I voted for "invoke", which is what the button does.
-
Against clickaction, because it's not just the click that triggers it.
-
-
Some comments mentioned "invoke" was too confusing a name/concept:
-
So is invoke but it feels harder to read and more passive.
-
because “invokeaction” is unbearably techie (and sounds like it’s trying to be “invocation”, which sounds a lot cooler (a magic spell!) but not very professional
-
The replies contain a lot of ideas for alternate names, here are the most promiment:
type=foo.- However we're not sure this is worth pursuing due to the complexity & compat risk.
do=foo.- I don't have strong opinions on this. While it's short, it may be too ambigious.
action=foo.- Some people explicitly mentioned the symmetry with
formaction=and felt it gelled well with existing platform primitives. Obviously they do very different things. - This idea seems worth exploring; a button can have
action=,formaction=,interestaction=, but the symmetry is lost with targets which would likely beactiontarget=,form=,interesttarget=.
- Some people explicitly mentioned the symmetry with
/cc @mfreed7 @smaug---- @annevk
The arguments against click are mostly about it not being device-independent, but the web platform click is device-independent as settled long ago. (And some of the comments you included there seem to apply to invoke instead or to both.)
Indeed, click is already device-independent, so technically speaking, clickaction is not an issue. However, ordinary developers might not necessarily understand this point. On the other hand, the name clickactiontarget is a bit lengthy (and due to naming conventions being all lowercase without separation, it also makes reading a bit more difficult). So I would slightly prefer invoketarget and invokeaction. Though I also much like shorter names like <button do="close" for="my-dialog">
action=foo is likely not web compatible, since that was the original name of formaction and it had to be changed because action broke websites.
I'm OK with the current names, but something like command and commandtarget (or commandfor) could work too.
The Open UI Community Group just discussed [invokers] bikeshed the attribute names..
The full IRC log of that discussion
<hdv> masonf: we just discussed this one at the WHATNOT meeting<hdv> masonf: we did some additional bikeshedding
<hdv> masonf: my action item is to collect all proposals for different names for these attributes
<hdv> masonf: there was also some discussion re a different syntax with a single attribute with multiple tokens in it, we resolved to keep it as it is now, with two attributes
<hdv> masonf: so now the question becomes, is it invoke, action, etc
<hdv> masonf: there was a strong opinion for it to be short and that the action one can be longer than the targetaction one
<masonf> q?
<keithamus> q+
<brecht_dr> q+
<hdv> Luke: people who asked for just 'action' but we can't do that for legit reasons not because we don't like it
<hdv> masonf: common words are commonly used
<hdv> keithamus: probably wouldn't break Firefox, discussed with Ollie who seemed supportive
<hdv> keithamus: my conclusion from the survey we did was… it was fairly even distribution of opinions
<dbaron> s/Ollie/Olli/
<hdv> keithamus: out of the current names, command seems to be short, useful… it got the lowest vote but they were all pretty much around 30%
<hdv> Luke: there was some pushback
<masonf> q?
<masonf> ack keith
<hdv> masonf: my take on the survey, if the survey has equal results, they mean just ship the thing, don't care about the name
<masonf> ack brecht
<hdv> brecht_dr: what about the same pattern as onclick, eg oninvoke ?
<hdv> brecht_dr: is that too far fetched?
<keithamus> q+
<hdv> Luke: I don't think using on-prefix is doable
<hdv> keithamus: we might want an oninvoke on an element to listen to the invoke element but would be on the receiving element
<hdv> Luke: if we come up with command, what do we call the feature?
<hdv> Luke: invoker, invoke api etc works, but with command? there's markup actions, not a fan
<masonf> ack keith
<keithamus> https://github.com/whatwg/html/issues/9625
<hdv> keithamus: could we do research the compat issues to not go around the merry go round?
<hdv> masonf: yes if someone wants to do it seems this would be data retrievable from httparchive
<hdv> masonf: can also suggest that in the comment
<hdv> Luke: there were lots of comments that clickaction was confusing
<hdv> masonf: I also heard that multiple times
Please see https://github.com/whatwg/html/issues/9625#issuecomment-2127894305
The Open UI Community Group just discussed [invokers] bikeshed the attribute names..
The full IRC log of that discussion
<hdv> gregwhitworth: this issue is about bikeshedding the attribute names<masonf> See this: https://github.com/whatwg/html/issues/9625#issuecomment-2127894305
<hdv> keithamus: Apple rejected the notion of invoke in their standards position and then suggested it be something with click in the name
<hdv> keithamus: we then had a survey go out… there was a preference for command because it's what's used in @@@
<gregwhitworth> q+ naman
<hdv> keithamus: and Webkit's position was they're happiest with click
<hdv> masonf: last time there was the idea to maybe put out another poll
<keithamus> s/@@@/XUL
<hdv> masonf: we have a list, if you have a great idea better than that list, put it out
<hdv> masonf: and then we can repost another poll
<gregwhitworth> ack naman
<hdv> masonf: part of the old poll was 'clickaction' which sounds great but isn't if you look at all the other options, so in the new poll we should make sure we cover different implications
<masonf> q?
<hdv> nmn: having read the proposal, I like the idea that there is click in there, because 'invoke' tells me what will be affected but not how… we're supposed to know that clicking causes the invoking, but there are many other ways it can work
<hdv> q+
<gregwhitworth> ack hdv
<Luke> q+
<gregwhitworth> hdv: I was going to say what Mason said, I don't think it's the right word because it invokes on many other ways
<gregwhitworth> hdv: they do more than just click, maybe this is a chance to do a better word
<gregwhitworth> naman: I think that makes the whole discussion more confusing, since we can't break the other solutions
<hdv> masonf: there's the idea that click isn't right because invoking happens on other events as well. but than that's the same for click event today
<gregwhitworth> naman: Click is way bigger than mouse click
<masonf> q+
<gregwhitworth> ack Luke
<hdv> Luke: I'm in the camp of not liking click… if the el is keyboard focusable it will fire a click event if you access it with keyboard
<hdv> Luke: why I don't like click is that we intentionally avoided input names for invokers
<hdv> Luke: just because the event is click, doesn't mean the action has to be click as well
<hdv> Luke: also, it;'s invoketarget and invokeaction is basically the same length… with the other proposal one is longer than the other
<hdv> Luke: we might have implicit targets
<hdv> Luke: the word invoke is good because it is separate from click
<gregwhitworth> q?
<hdv> Luke: this is why command works relatively well I feel, you're commanding another element as it where
<hdv> Luke: ultimately the utility is the important bit
<hdv> Luke: I wonder if a new poll will help? even if invoke wins, probably won't change Apple's minds
<hdv> nmn: risk of the poll is that there is a strong selection bias of who participates in the first place
<hdv> masonf: agreed
<gregwhitworth> ack masonf
<hdv> masonf: controls=idref and control="the action" is an interesting idea, might add to the poll
<hdv> s/controls/Luke, controls
<gregwhitworth> q+ naman
<hdv> masonf: one thing I like is the idfref based attribute name, so I like things with target in the name
<hdv> masonf: I do understand that invoke is a weird word for non native English speakers
<keithamus> q+
<nmn> is `action` and `actionTarget` viable options?
<gregwhitworth> ack naman
<keithamus> q+ muan
<hdv> masonf: we could potentially also remove 'invoke' from the poll so that we could force getting a different result…
<hdv> nmn: are action and actiontarget going to work?
<hdv> Luke: there is an issue, I think related to form action
<flackr> actiontype maybe?
<gregwhitworth> ack keithamus
<hdv> keithamus: click isn't transitive verb, controls is, which makes sense here? maybe we can find a transitive verb… controls, target and controls is
<gregwhitworth> ack muan
<hdv> s/controls,//
<hdv> muan: target is the reason why things got longer… have we thought about for, like commandfor, like with labels?
<hdv> masonf: 'for' has been discussed and dismissed, but not as a suffix
<hdv> Luke: yeah if we have for it would have to be a suffix
<hdv> masonf: I'll add this suggestion in
<gregwhitworth> ack dbaron
<hdv> dbaron: good thoughts
<hdv> dbaron: what I came on the queue for… wasn't sure what the proposal was with 'control'… seems like the nuance of English grammar may be a bit opaque to non native English speakers
<masonf> the proposal was "<controls=idref controlaction=action>" and I agree the trailing "s" does a lot of work there.
<hdv> dbaron: based on what muan said, we could also think of using id as a suffix
<hdv> dbaron: not sure if there's a precedent for this
<gregwhitworth> q?
<hdv> flackr: maybe backwards to the usual relation?
<hdv> masonf: depends on how you use it… eg clickactionid ?
<hdv> nmn: makes it sound like view transition name, you can invoke me with this id
<keithamus> q+
<hdv> masonf: these are great suggestions that I can add to the list. Maybe I can add this to the WHATWG issue, give it some time and then after come back to the issue
<gregwhitworth> ack keithamus
<hdv> masonf: could do a poll some other time, not right now
<masonf> q+
<hdv> keithamus: don't think polling would be massively useful… as it's is probably unlikely to persuade specific vendors.
<gregwhitworth> ack masonf
<hdv> masonf: agreed… what I meant to say… I add the new suggestions to the list in the other issue and share we had a good discussion here, and suggest one would be picked
<hdv> masonf: from my point of view I don't really mind what it ends up being
<hdv> gregwhitworth: the poll is still a hundred more people than 2
<hdv> gregwhitworth: maybe this is a good one to put on the agenda of the task force
<hdv> masonf: will be a few weeks away because of CSS F2F and CSS Day
@keithamus @mfreed7 just read through the novel that is the WHATWG thread. Looks like the naming is cemented. Is there a reason to keep this issue open any longer?
We can close for now. We can re-open this if we need to.
For posterity: WHATWG resolved to explore commandfor and command over invoketarget and invokeaction respectively.