Add support for 'enterkeyhint' attribute (was 'inputmodeaction') #3538

dtapuska · 2018-03-06T21:25:16Z

~~inputmodeaction~~ enterkeyhint allows an author to configure what type of iconify is
displayed in place for the enter key on virtual keyboards.

Tests: Soon

/dom.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/interaction.html ( diff )

dtapuska · 2018-03-06T21:27:16Z

@domenic thoughts?

domenic · 2018-03-07T02:11:34Z

I assume "iconify" is "icon"?

Exposing this capability to web apps makes a lot of sense to me. I haven't looked too much at the details yet besides seeing that there's a table of common actions and that this is a hint. It seems like a nice enhancement with no compat concerns in browsers that don't support it, which is nice.

@othermaciej, any thoughts as to whether this would be something interesting for mobile Safari?

@travisleithead, any thoughts as to whether this would be something interesting for Windows 10's touch keyboard for Edge? Maybe there's already a UWP API for this and you've just been itching to expose it to PWAs?

@bzbarsky, any thoughts for Mozilla on the platforms it runs on?

I'll try to dive in to the actual spec PR after giving this a few days to gather implementer interest.

othermaciej · 2018-03-07T03:11:04Z

Is there a high-level explanation of this pproposal or do I need to just read the diff text?

dtapuska · 2018-03-07T03:36:31Z

You'll need to read the spec test. But basically this is moz-actionhint in a spec... See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-mozactionhint (with the enter keyword added)

bzbarsky · 2018-03-07T03:55:35Z

The current implementation of this stuff in Gecko is basically Android-only. We pass the string around on all platforms, but Android is the only one that does anything with it.

The people who implemented this initially are no longer active, and this is the first time I've heard of this attribute myself, so I can't say much more than what I see through code archeology.... It was added in https://bugzilla.mozilla.org/show_bug.cgi?id=589879 largely because Firefox on Android at the time was using web tech for its own UI (mostly; like Firefox desktop does now) and this was needed for the URL bar UI. There was some spirited debate about this implementation and the fact that it was web-exposed (see https://bugzilla.mozilla.org/show_bug.cgi?id=614488 for example).

At this point there is one internal consumer (the "search texbox" widget)... which seems to not be used in the Android UI anywhere. So I think at this point mozactionhint is basically dead code we could remove with no observable effects.

What this means in terms of exposing it to the web, I'm not sure. ;)

If there's a more specific question, I can try to find people who might be able to answer it.

domenic · 2018-03-07T03:58:45Z

I think the more specific question is, would Mozilla be interested in exposing a standardized version of the attribute? Instead of deleting their nonstandard one :)

bzbarsky · 2018-03-07T04:05:10Z

That sounds like a question for https://github.com/mozilla/standards-positions.

annevk · 2018-03-07T05:26:05Z

Filed mozilla/standards-positions#68.

rniwa · 2018-03-08T03:53:33Z

The idea of making enter key customizable and the list of options in the proposal seems good. iOS allows native apps to do almost exactly this for clarify in UI.

Nonetheless, I don't think it makes much sense to call this content attribute inputmodeaction since this doesn't affect what kind of things can be input, or the mode of input. It's really describing what happens when an user presses enter after the user had finished input text.

Maybe returnkeyaction or enterkeyaction would work better?

othermaciej · 2018-03-08T03:57:34Z

Perhaps just returnraction or even action?

annevk · 2018-03-08T03:58:59Z

I think the nice thing about the name is that inputmode describes the type of virtual keyboard, and inputmodeaction describes the look of the action key on that virtual keyboard. Makes it easier to tell that they are related.

dtapuska · 2018-03-08T04:03:32Z

FWIW I've been writing the chromium code for this today and I have been calling it inputaction for the structs (because InputModeAction was too long); I only used that name for the html element attribute.

But I named it exactly as @annevk described.

othermaciej · 2018-03-08T04:11:57Z

That naming logic seems too indirect to be obvious. It's true that inputmode is an indirect way of referencing the keyboard, but why not just reference it directly? I think knowing that this is about the return key on the keyboard is more important than knowing that this affects something that is also affected by the inputmode attribute. (That said, this is kind of bikeshedding).

domenic · 2018-03-08T04:47:50Z

Personally I'm leaning toward either inputmodeaction or inputaction. Note that this can appear on contenteditable elements or textarea elements or similar, so just action seems less good.

If we'd called inputmode keyboardmode instead, then something like keyboardaction would make sense. I'm not sure what the reasoning was there exactly, but at this point it'd be nice to be consistent in at least one dimension.

Does anyone have comments on the set of actions? I imagine @dtapuska has done the research on how they line up with various platforms, and platforms can always fall back to a default if not supported, but e.g. did anything get left out?

annevk · 2018-03-08T04:55:43Z

Given that this is global, action would conflict badly on form elements.

Zirro · 2018-03-08T15:16:12Z

As someone encountering this attribute for the first time, I find the names ending with action to be confusing. I'd expect an attribute named inputaction to determine which action is invoked in a certain context, but this is only about the label/visual indicator.

Based on this, I would suggest names along the lines of actionlabel, enterlabel or keylabel instead.

othermaciej · 2018-03-08T16:18:18Z

actionlabel and enterlabel (or returnabel) all seem very on point given what this does.

dtapuska · 2018-08-24T15:09:42Z

Ok I've renamed it inputactionlabel is that better? Being that it appears on the HTMLElement I think it needs "input" in the prefix.

annevk

Overall this looks good, but I found a couple of issues.

annevk · 2018-08-27T07:37:16Z

source

+  contenteditable</code>).</p>
+
+  <p>The <dfn><code data-x="attr-inputactionlabel">inputactionlabel</code></dfn> content attribute is an
+  <span>enumerated attribute</span> that specifies what kind of iconify for the enter key on


s/iconify/icon/?

Or maybe use "action label" throughout?

annevk · 2018-08-27T07:38:41Z

source

+
+  <p>User agents can support the <code data-x="attr-inputactionlabel">inputactionlabel</code> attribute
+  on form controls (such as the value of <code>textarea</code> elements), or in elements in an
+  <span>editing host</span> (e.g., using <code data-x="attr-contenteditable">


You cannot break after a tag, that'll add whitespace to its contents.

annevk · 2018-08-27T07:40:44Z

source

+
+  <p>When <code data-x="attr-inputactionlabel">inputactionlabel</code> is unspecified (or is in a state not
+  supported by the user agent), the user agent should determine the default action type to be
+  shown. Contextual information such as the <code data-x="attr-inputmode">inputmode</code>, input


I'd drop input here since it's not part of the attribute name.

annevk · 2018-08-27T07:40:59Z

source

+  <p>When <code data-x="attr-inputactionlabel">inputactionlabel</code> is unspecified (or is in a state not
+  supported by the user agent), the user agent should determine the default action type to be
+  shown. Contextual information such as the <code data-x="attr-inputmode">inputmode</code>, input
+  <code data-x="attr-input-type">type</code> or <code data-x="attr-input-pattern">pattern</code> attributes


Oxford commas please.

annevk · 2018-08-27T07:43:58Z

source

+   <tbody>
+    <tr>
+     <td><dfn><code data-x="attr-inputactionlabel-keyword-enter">enter</code></dfn>
+     <td>The user agent should display a visual queue of the operation 'enter'.


Do you mean "visual cue"? Why visual though? Presumably assistive technology can also use this?

Ugh yes. it should be cue. I've removed visual and display and used the verb present.

annevk

LGTM with my own nits applied (please double check), but needs tests and implementation bugs before merging.

Thanks for pushing this forward!

domenic · 2018-08-30T19:26:26Z

@rniwa / @othermaciej, are you happy with the name inputactionlabel?

othermaciej · 2018-08-30T20:57:50Z

inputactionlabel seems better than the original inputmodeaction. But it still seems a little hard to understand what it does from the name alone. If I was reading it without context, I'd wonder "what exactly is an input action, and why would I label it?" I still think super literal names like returkeylabel are better in this regard.

I understand the desire to use input as a sort of prefix for a set of related properties, to make the tie to inputmode. But I don't think that works here. The natural way to interpret the word "input" in these attribute names is as an adjectival noun modifying the following word, not as a category prefix. That's the way it works in inputmode, where it modifies the word "mode" to explain what type of mode. "input mode" is a pre-existing widely understood term. But "input action" is not a commonly used term, and if there even was such a term, there isn't an intent to refer to it here. That's what makes it a bit mysterious to read.

If it came down to it I don't think we'd hold off on implementing based on the name alone. It doesn't seem like the most important aspect of this feature. But I thought I'd share my view nonetheless.

Added previous keyboard somehow it never made it in

domenic · 2018-09-11T21:23:34Z

LGTM! Ready to merge once we have some tests to link to. As with inputmode I anticipate the tests will be pretty basic, just testing the reflection I guess.

annevk · 2018-09-12T07:22:30Z

Unless I missed something we'll also need implementation bugs.

dtapuska · 2018-09-12T13:08:12Z

Are these good enough?

https://bugzilla.mozilla.org/show_bug.cgi?id=1490661
https://crbug.com/634330

domenic · 2018-09-12T14:06:20Z

Will need WebKit and Edge too. See https://github.com/whatwg/meta/blob/master/MAINTAINERS.md#handling-pull-requests . (We should probably move that to CONTRIBUTING.md, not just MAINTAINERS.md...)

dtapuska · 2018-09-12T14:22:38Z

Done...

Edge https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/18970983/
Safari https://bugs.webkit.org/show_bug.cgi?id=189546

dtapuska · 2018-09-12T15:57:16Z

Web platform tests are included in Chrome's implementation CL here: https://chromium-review.googlesource.com/c/chromium/src/+/1221696

enterKeyHint allows customization of the virtual keyboard enter key. Enabled behind a flag since it isn't approved to ship yet. Spec: whatwg/html#3538 BUG=634330 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng Change-Id: I32b510d8157e0c676300a38bb4c7fa2bbced0b3d

Halochkin · 2018-12-25T15:33:12Z

Does it make sense? Nowadays smartphones have virtual keyboards with just "↵" symbol on enter key instead text value.

enterKeyHint allows customization of the virtual keyboard enter key. Enabled behind a flag since it isn't approved to ship yet. Spec: whatwg/html#3538 BUG=634330 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng Change-Id: I32b510d8157e0c676300a38bb4c7fa2bbced0b3d

enterKeyHint allows customization of the virtual keyboard enter key. Enabled behind a flag since it isn't approved to ship yet. Spec: whatwg/html#3538 BUG=634330 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng Change-Id: I32b510d8157e0c676300a38bb4c7fa2bbced0b3d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1221696 Commit-Queue: Dave Tapuska <[email protected]> Reviewed-by: Jeremy Roman <[email protected]> Reviewed-by: Changwan Ryu <[email protected]> Reviewed-by: Avi Drissman <[email protected]> Reviewed-by: Ken Buchanan <[email protected]> Reviewed-by: Joshua Bell <[email protected]> Cr-Commit-Position: refs/heads/master@{#661904}

…t., a=testonly Automatic update from web-platform-tests Add experimental support for enterKeyHint. enterKeyHint allows customization of the virtual keyboard enter key. Enabled behind a flag since it isn't approved to ship yet. Spec: whatwg/html#3538 BUG=634330 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng Change-Id: I32b510d8157e0c676300a38bb4c7fa2bbced0b3d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1221696 Commit-Queue: Dave Tapuska <[email protected]> Reviewed-by: Jeremy Roman <[email protected]> Reviewed-by: Changwan Ryu <[email protected]> Reviewed-by: Avi Drissman <[email protected]> Reviewed-by: Ken Buchanan <[email protected]> Reviewed-by: Joshua Bell <[email protected]> Cr-Commit-Position: refs/heads/master@{#661904} -- wp5At-commits: 74870bb3fbf231c8b89f529fbfea7f22ad149c33 wpt-pr: 16718

sideshowbarker · 2019-06-22T04:22:58Z

heads-up @whatwg/documentation

Intent to Ship for Chrome: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Hfe5xktjSV8/Re-SMF3wAwAJ
open Firefox feature bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1490661
open Safari feature bug: https://bugs.webkit.org/show_bug.cgi?id=189546

chrisdavidmills · 2019-06-22T18:39:22Z

MDN documentation need recorded at https://trello.com/c/aBs1o6Pg/86-dom-general-enhancements-fx-68

enterKeyHint allows customization of the virtual keyboard enter key. Enabled behind a flag since it isn't approved to ship yet. Spec: whatwg/html#3538 BUG=634330 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng Change-Id: I32b510d8157e0c676300a38bb4c7fa2bbced0b3d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1221696 Commit-Queue: Dave Tapuska <[email protected]> Reviewed-by: Jeremy Roman <[email protected]> Reviewed-by: Changwan Ryu <[email protected]> Reviewed-by: Avi Drissman <[email protected]> Reviewed-by: Ken Buchanan <[email protected]> Reviewed-by: Joshua Bell <[email protected]> Cr-Commit-Position: refs/heads/master@{#661904}

hober · 2019-10-30T17:33:03Z

Support in WebKit landed in r251720.

domenic added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest labels Mar 7, 2018

annevk mentioned this pull request Mar 7, 2018

HTML: enterkeyhint attribute mozilla/standards-positions#68

Closed

dtapuska force-pushed the master branch from 75c554c to 807bd3c Compare August 24, 2018 15:08

annevk reviewed Aug 27, 2018

View reviewed changes

annevk added topic: forms and removed needs implementer interest Moving the issue forward requires implementers to express interest labels Aug 27, 2018

dtapuska force-pushed the master branch from 807bd3c to 39117bd Compare August 29, 2018 19:22

annevk added the needs tests Moving the issue forward requires someone to write tests label Aug 30, 2018

annevk approved these changes Aug 30, 2018

View reviewed changes

Add additional text clarifying actions

bfc79df

Added previous keyboard somehow it never made it in

sideshowbarker added the impacts documentation Used by documentation communities, such as MDN, to track changes that impact documentation label Sep 11, 2018

chromium-wpt-export-bot mentioned this pull request Sep 12, 2018

Add experimental support for enterKeyHint. web-platform-tests/wpt#12972

Closed

domenic removed the needs tests Moving the issue forward requires someone to write tests label Sep 12, 2018

domenic merged commit a5422d9 into whatwg:master Sep 12, 2018

chromium-wpt-export-bot mentioned this pull request May 7, 2019

Add experimental support for enterKeyHint. web-platform-tests/wpt#16718

Merged

dtapuska mentioned this pull request May 21, 2019

Ability to customize virtual keyboard via enterkeyhint w3ctag/design-reviews#380

Closed

5 tasks

sideshowbarker changed the title ~~Add support for inputmodeaction.~~ Add support for 'enterkeyhint' attribute (was 'inputmodeaction') Jun 22, 2019

gked mentioned this pull request Mar 17, 2020

July 29th F2F Agenda Item - Set Virtual Keyboard Enter Key Text w3c/editing#142

Closed

Add support for 'enterkeyhint' attribute (was 'inputmodeaction') #3538

Add support for 'enterkeyhint' attribute (was 'inputmodeaction') #3538

Conversation

dtapuska commented Mar 6, 2018 • edited by sideshowbarker Loading

dtapuska commented Mar 6, 2018

domenic commented Mar 7, 2018

othermaciej commented Mar 7, 2018

dtapuska commented Mar 7, 2018

bzbarsky commented Mar 7, 2018

domenic commented Mar 7, 2018

bzbarsky commented Mar 7, 2018

annevk commented Mar 7, 2018

rniwa commented Mar 8, 2018

othermaciej commented Mar 8, 2018

annevk commented Mar 8, 2018

dtapuska commented Mar 8, 2018

othermaciej commented Mar 8, 2018

domenic commented Mar 8, 2018 • edited Loading

annevk commented Mar 8, 2018

Zirro commented Mar 8, 2018

othermaciej commented Mar 8, 2018

dtapuska commented Aug 24, 2018

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

domenic commented Aug 30, 2018

othermaciej commented Aug 30, 2018

domenic commented Sep 11, 2018

annevk commented Sep 12, 2018

dtapuska commented Sep 12, 2018

domenic commented Sep 12, 2018

dtapuska commented Sep 12, 2018

dtapuska commented Sep 12, 2018

Halochkin commented Dec 25, 2018 • edited Loading

sideshowbarker commented Jun 22, 2019

chrisdavidmills commented Jun 22, 2019

hober commented Oct 30, 2019

dtapuska commented Mar 6, 2018 •

edited by sideshowbarker

Loading

domenic commented Mar 8, 2018 •

edited

Loading

Halochkin commented Dec 25, 2018 •

edited

Loading