[invokers] Casing for action values

[lukewarlow]

It was raised by Jake Archibald that the current action values might not match expectations. https://w3ctag.github.io/design-principles/#casing-rules specifically says that enumeration values should be kebab-case.

Should these be enumeration values?

If so how do we achieve the custom action naming requirements we resolved upon?

Potentially this is a question we should pose to the W3C tag review?

[css-meeting-bot]

The Open UI Community Group just discussed [invokers] Casing for action values.

The full IRC log of that discussion

<masonf> q+
<hdv> Luke: this one was brought op by Jake Archibald… the casing should maybe kebab case, but if it is, how do we deal with casing requirements with regards to kebab case being custom that we talked about last wek?
<hdv> s/wek/week
<hdv> ack masonf
<hdv> masonf: agree kebab casing makes more sense, but stand by what we agreed last week, that we need a rule for custom vs standard
<hdv> Luke: if we use dash for cusom one it might work too?
<hdv> masonf: css custom state uses that? are there native HTML things that have something other than dash like double dash?
<hdv> Luke: not sure if HTML has a concept of custom values?
<masonf> q?
<hdv> masonf: except for custom elements that have a single dash requirement
<hdv> keithamus: CSS custom state is no longer dashed either
<hdv> masonf: I thought it still had double dash inside
<hdv> keithamus: no
<hdv> masonf: something namespaced like `custom: `
<hdv> masonf: how would you like to resolve this?
<hdv> Luke: maybe ask TAG this is what we have what would the alternative be
<hdv> masonf: I like the idea
<masonf> q?
<hdv> keithamus: I think we should think about TAG rejecting the proposal as is on those principles… and think about what we can do?
<hdv> keithamus: TAG might give as an alternative back, but not sure if that's how they operate?
<hdv> keithamus: would they?
<hdv> masonf: if we pose it as a question, the answer should hopefully more than just 'this doesn't work'
<hdv> bkardell_: if you have a question about what TAG is like or would do, could ask david who was on there and is here
<hdv> dbaron: would think it's likely they give a suggstion normally
<hdv> masonf: I'd hope this kind of question should be good
<masonf> q?
<hdv> keithamus: most of the rest of proposal details have landed or settled… proposal is in a good state in Chrome, I believe… most of what we're blocked on is what do we do about dialog and all of the naming… but rest of the details seem minor
<hdv> masonf: maybe to help that, propose something and say 'here's what we think is the best option and let us know if you have a better suggestion'
<hdv> dbaron: another thing about taking to the TAG… make sure there is a single clear description of the thing. the TAG won't go dig through the rest of the issues to find more info
<hdv> Luke: should we try to get the existing pull request to be merged, and then add one to explain the probllems?
<masonf> q?

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[keithamus]

https://github.com/openui/open-ui/labels/agenda%2B To discuss this change again, especially with regard to custom action heuristics.

[css-meeting-bot]

The Open UI Community Group just discussed [invokers] Casing for action values, and agreed to the following:

• RESOLVED: use kebab-case for command values.
• RESOLVED: have a specified namespace for custom command values.
• RESOLVED: use a double-dash prefix for custom command values.

The full IRC log of that discussion

<hdv> keithamus: the issue talks about using snake case instead of kebab case
<hdv> keithamus: our current system is that built in names are all one word, no dash
<hdv> keithamus: but spec precedent says it should @@@
<hdv> keithamus: this leads us to next problem… heuristic for custom values is that they have a dash
<hdv> scribenick: hdv
<hdv> keithamus: does anyone know of better options?
<masonf> q+
<hdv> keithamus: there are single word attr values like close
<hdv> keithamus: the other option is to add a custom attribute like customcommand instead of command, but that's complex
<hdv> keithamus: or prefixes or suffixes
<hdv> s/prefixes/use prefixes
<hdv> keithamus: any opinions on this?
<hdv> ack mas
<hdv> masonf: did you say 969 is kind of moot as it would need to be kebab case and was resolved?
<hdv> keithamus: kind of put this on so that we can segway to custom values
<hdv> keithamus: the whatwg conclusion didn't seem entirely satisfactory
<hdv> keithamus: as there seems not really a way to navigate around the dashes
<hdv> masonf: on the queue to say… moving to kebab case for everything
<hdv> masonf: it always sort of bothered me to have both cases
<hdv> masonf: I think we'll need a namespace
<hdv> masonf: for the naming scheme, I think single dash is funny, not sure if it exists anywhere else?
<hdv> masonf: we do have -- in CSS that we're using for most new things
<hdv> masonf: would love to hear if single dash feels confusing or natural?
<hdv> s/natural?/natural to developers?
<masonf> q?
<hdv> masonf: I have no strong feelings except that we need something distinct
<hdv> keithamus: I'm not strong on having a namespace… every namespace issue can be worked around
<masonf> q+
<hdv> keithamus: namespace clashes are not ideal but they are always resolvable in some way or another
<bkardell_> q+
<masonf> q+ bkardell_
<hdv> keithamus: re double dash… I think there's a convo we'd probably need to have with CSS maintainers… at the moment you can use an attr selector… isn't this kind of a reserved grammar in CSS?
<hdv> ack mas
<hdv> masonf: are you concerned there was a namespace collision, that something would not work in CSS?
<hdv> keithamus: not today but maybe we'd be closing the door for something to work in the future in CSS?
<hdv> masonf: if there is a potential for a collison, you're right
<hdv> masonf: I do think they're namespaced enough
<keithamus> `.foo[attr=--bar]` is a valid CSS selector today I believe
<hdv> ack mas
<hdv> masonf: you said you'd be ok with namespace issues? in my experience it can result in a lot of work
<hdv> masonf: I spent about a year of calendar time renaming popup in code to popover that can't spend anywhere else
<masonf> q?
<hdv> masonf: if there's a compat constraint that comes in later it can result in a lot of work
<hdv> keithamus: have no experience, but I respect that position
<hdv> keithamus: there's nothing really in JS or HTML, other than custom elements… but I guess other is doing a lot of heavy lifting
<hdv> ack bk
<hdv> bkardell_: question: are there attributes historically that were browser prefixed attributes?
<hdv> bkardell_: the reason of the particulars in CSS is that CSS has forward compatible grammar, all places in CSS where you could have something, property, value, selector, media query… all of those had prethought how you could do it with vendor prefix
<hdv> bkardell_: because of that double dash worked
<hdv> bkardell_: if something like that existed for attributes I'd think that'd potentially be a solution for attributes too, not sure I know of any though
<hdv> bkardell_: I like matching CSS personally
<keithamus> q+
<hdv> masonf: more relevant concern for me… I think what's important is what makes sense to developers
<hdv> bkardell_: at the time we also compared it to data-
<hdv> q+
<hdv> keithamus: given your discussion on -- in web history… a single dash doesn't preclude a double dash, but it also allows for component systems to supply their own vendor prefixes, so you could have a -shoelace-command to avoid collisions
<masonf> Just to say: isn't conventional wisdom that vendor prefixes were a bad idea?
<hdv> bkardell_: would also work with -- though
<hdv> ack keith
<masonf> hdv: +1 to the double-dash being familiar to developers.
<masonf> hdv: seems natural
<masonf> ack hdv
<hdv> ack me
<hdv> masonf: should we discuss whether there should be a namespace
<masonf> Proposed resolution: use kebab-case for command values.
<hdv> keithamus: I think there's more interest in custom commands than in dialog
<masonf> Proposed resolution: have a specified namespace for custom command values.
<hdv> masonf: so re namespace you'd be ok with saying let's have a custom namespace
<hdv> keithamus: yea but am ambivlaent
<hdv> s/ambivlaent/ambivalent
<keithamus> +1
<bkardell_> lolol
<hdv> +1
<keithamus> (+1 to the first and +0 to the second)
<philippgfeller> +1
<masonf> RESOLVED: use kebab-case for command values.
<masonf> RESOLVED: have a specified namespace for custom command values.
<masonf> q?
<keithamus> https://github.com/openui/open-ui/issues/900 < prior resolution here
<hdv> which GH issue is this?
<keithamus> https://github.com/openui/open-ui/issues/969
<hdv> masonf: any other contenders for names other than - or -- ?
<hdv> masonf: think it would be helpful to have discussed it here when we take it to whatwg
<hdv> keithamus: generally seemed to me that - or -- would both be acceptable to WHATWG
<masonf> Options: 1) single-dash prefix, 2) double-dash prefix, 3) any non-alphanumeric prefix
<hdv> keithamus: also wondered if any symbol could be valid so that folks could choose what they want, but seemed to have a fixed symbol was preferred
<gregwhitworth> 2
<philippgfeller> 2
<keithamus> 1
<hdv> 2
<masonf> 2
<scott> 2
<bkardell_> 3
<bkardell_> whoops
<bkardell_> 2
<sanketj_> 2
<hdv> Options: 1) single-dash prefix, 2) double-dash prefix, 3) any non-alphanumeric prefix
<una> 3
<jarhar> 1
<masonf> RESOLVED: use a double-dash prefix for custom command values.
<hdv> masonf: I see 7 for 2, and less for others, would call that resolved for double dash
<una> double dash SGTM

[mfreed7]

Quick comment - we discussed the double-dash naming scheme in WHATNOT just now, and the WHATWG folks are ok with that conclusion. So it sounds like we should just change the explainer and spec PR accordingly, to say --foo is a custom command name.

Side note: another suggestion was made, for command: data-custom-name. I.e. the prefix could be data-. My guess was that folks wouldn't like that idea much, but I could be wrong, so please chime in if you have strong feelings that data- would be a better choice for a prefix. Barring that, I think this issue and https://github.com/openui/open-ui/issues/954 can likely both be closed as Fixed, once the relevant PR edits have been made.