Intent to Implement and Ship: Enter Key Hint

324 views
Skip to first unread message

Dave Tapuska

unread,
May 17, 2019, 5:33:16 PM5/17/19
to blink-dev
dtap...@chromium.org https://html.spec.whatwg.org/multipage/interaction.html#input-modalities:-the-enterkeyhint-attribute Specification: https://html.spec.whatwg.org/multipage/interaction.html#input-modalities:-the-enterkeyhint-attribute Minor additional API already in HTML spec. Add the ability to customize the enter key on mobile devices virtual keyboards To be able to build rich applications that customize the enter key.
Enter key will be dispatched always when enterKeyHint is specified. This is slightly different behaviour inside a form control if you didn't specify the hint it automatically moves to the next field. I don't expect any real interop issues because of it though. Firefox: Public support https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-mozactionhint was shipped this behind an alternate name before standardization.

https://github.com/mozilla/standards-positions/issues/68 Edge: No public signals Safari: Public support
Web developers: No signals
Yes Yes https://wpt.fyi/results/html/dom/interfaces.https.html%3Finclude%3DHTML.*?label=master&product=chrome%5Bexperimental%5D&product=edge&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned https://bugs.chromium.org/p/chromium/issues/detail?id=634330 http://output.jsbin.com/mukira https://www.chromestatus.com/features/5654529808793600

Daniel Bratell

unread,
May 20, 2019, 8:06:37 AM5/20/19
to blink-dev, Dave Tapuska
In the html spec it seems like enterkeyhint only controls what text/icon a
virtual keyboard should put on the enter/done/finish/continue button, not
that the browser should change behaviour in any way.

Is the difference you mention in the compatibility session because virtual
keyboards may change their behaviour because of the hint? When I try a
virtual keyboard in a textarea today it inserts line breaks when I press
the enter button. May depend on virtual keyboard/browser?

/Daniel

On Fri, 17 May 2019 23:32:59 +0200, Dave Tapuska <dtap...@chromium.org>
wrote:
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
>
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev>+unsub...@chromium.org.
>
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/>CAHgVhZVg77YtpVnGfXfC-_9LDtW-ViPMdtLzxpnAP1VA2fdiew%40mail.gmail.com.
>



--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

Dave Tapuska

unread,
May 20, 2019, 8:48:03 AM5/20/19
to Daniel Bratell, blink-dev
The enterkey hint always produces a keydown, keypress, keyup event. In textareas this is what causes the new line to be inserted. The behaviour is no different.

The different behaviour comes into play with the enter key on inputs inside a form control. For those inputs the Android browser code traps the enter key before sending it to blink and moves focus to the next field. The behaviour here will be slightly different because we will now send the keydown, keypress, keyup events. So if the page placed the enterkeyhint on the inputs and it doesn't have enterkey handlers or marked fields as required it may find the form submitted. (because that is the default action for enter key on inputs inside a form in blink). I don't think this is a big deal because desktop browsers and mobile firefox already do this and it matches the standard. But I wanted to call it out. 

Dave

Daniel Bratell

unread,
May 20, 2019, 9:52:03 AM5/20/19
to Dave Tapuska, blink-dev
Ok, so any use of enterkeyhint, including enterkeyhint="next" will delegate to the web page to handle the enter events?

And <textarea>, which I checked, is already different from <input> in this case?

/Daniel

Yoav Weiss

unread,
May 20, 2019, 11:04:53 AM5/20/19
to Dave Tapuska, blink-dev
That's not an explainer. A few sentences explaining what use-cases this is trying to solve, and showing a couple of examples would go a long way to help people immediately understand what that thing is and what it is supposed to be doing. See https://github.com/w3ctag/w3ctag.github.io/blob/master/explainers.md for more details and a useful template.
 
Specification: https://html.spec.whatwg.org/multipage/interaction.html#input-modalities:-the-enterkeyhint-attribute Minor additional API already in HTML spec.

That's not good justification for skipping a TAG review. See here for a previous discussion on that front.
 
Add the ability to customize the enter key on mobile devices virtual keyboards To be able to build rich applications that customize the enter key.
Enter key will be dispatched always when enterKeyHint is specified. This is slightly different behaviour inside a form control if you didn't specify the hint it automatically moves to the next field. I don't expect any real interop issues because of it though. Firefox: Public support https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-mozactionhint was shipped this behind an alternate name before standardization.

https://github.com/mozilla/standards-positions/issues/68 Edge: No public signals Safari: Public support
Web developers: No signals
Yes Yes https://wpt.fyi/results/html/dom/interfaces.https.html%3Finclude%3DHTML.*?label=master&product=chrome%5Bexperimental%5D&product=edge&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned https://bugs.chromium.org/p/chromium/issues/detail?id=634330 http://output.jsbin.com/mukira https://www.chromestatus.com/features/5654529808793600

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Dave Tapuska

unread,
May 20, 2019, 2:27:30 PM5/20/19
to Daniel Bratell, blink-dev
Yes to both your questions. 

Dave Tapuska

unread,
May 21, 2019, 12:22:52 PM5/21/19
to Daniel Bratell, blink-dev

Yoav Weiss

unread,
Jun 6, 2019, 5:07:13 AM6/6/19
to Dave Tapuska, Daniel Bratell, blink-dev
On Tue, May 21, 2019 at 6:22 PM Dave Tapuska <dtap...@chromium.org> wrote:

That's a great explainer, thank you! :)
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZWGc4LJwCYd%2BDJ59ib4VX0ZGEMkentcFtDHPCUq48R6uw%40mail.gmail.com.

oj...@google.com

unread,
Jun 6, 2019, 3:24:15 PM6/6/19
to blink-dev, dtap...@chromium.org, bra...@opera.com
LGTM1
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

Philip Jägenstedt

unread,
Jun 6, 2019, 4:56:06 PM6/6/19
to Ojan Vafai, blink-dev, Dave Tapuska, Daniel Bratell
Agreed on the explainer, nice screenshots :)

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5242e1bd-0119-4f1d-a1fd-25e8abcce409%40chromium.org.

Yoav Weiss

unread,
Jun 13, 2019, 2:17:19 PM6/13/19
to Philip Jägenstedt, Ojan Vafai, blink-dev, Dave Tapuska, Daniel Bratell
LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYft31M3uQifJ%2Brf4D%2B4KUpKii2mHGv0DqQHREMF5oTaLQ%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages