Intent to Ship: DOM KeyboardEvent.code attribute

[Dave Tapuska]

Contact emails:

dtap...@chromium.org, gar...@chromium.org

Spec:

https://w3c.github.io/uievents/

https://w3c.github.io/DOM-Level-3-Events-code/

Summary:

KeyboardEvent.code contains a standardized name of the physical key that has been pressed on a keyboard. The value presented does not change with modifiers pressed; currently this feature is not available in any way to the web. 

Motivation:

It is useful to determine which key was pressed on the keyboard irrespective of the modifiers and keyboard layout. For example gaming is often based on keyboard key location not necessarily the key that is actually generated.

Link to "Intent to Implement" blink-dev discussion:

Yes it has been over 2 years since implementation was proposed. We have seen FireFox implement this spec since 32.0

https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Dom$20code$20Intent$20to$20implement/blink-dev/Qz9OekVPHVE/74TE5BAQH40J

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes; although on Android some virtual keyboards intercept physical keyboard events and rewrite them to not provide the native scancode which makes using this feature on Android platform in specific configurations impossible. See https://crbug.com/535704

OWP launch bug:

https://crbug.com/227231

Feature dashboard:

https://www.chromestatus.com/feature/5228092293382144

[Emil A Eklund]

Are we also planning to ship KeyboardEvent.key? Shipping code without
key would be unfortunate.

[Dave Tapuska]

I will submit a separate proposal for that. There are a few things remaining before KeyboardEvent.key is ready. I don't believe they need to be tied to each other. Ultimately my goal is to have both shipped both in M48 if approved.

KeyboardEvent.key recently was promoted from testing to experimental; whereas KeyboardEvent.code has been experimental for a number of releases thus far.

DOM code is relatively simple and is pretty much code complete with one issue remaining to be fixed with IME. 

DOM key is more complex in terms of IME; dead key handling, etc. It is probably 75% implemented.

IE/Edge have shipped KeyboardEvent.key and not KeyboardEvent.code so there is precedence with having one and not the other.

Also I will file an intent to Deprecate KeyIdentifier around the same time when I ask to ship KeyboardEvent.key; so just sit tight for another week or two :-)

dave.

On Wed, Sep 30, 2015 at 10:19 AM, Emil A Eklund <e...@chromium.org> wrote:

Are we also planning to ship KeyboardEvent.key? Shipping code without
key would be unfortunate.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Emil A Eklund]

Thanks for the clarification, that makes sense. Non-OWNER LGTM.

[PhistucK]

Do you know whether Edge or Safari are going to implement this?

☆PhistucK

On Wed, Sep 30, 2015 at 5:35 PM, Emil A Eklund <e...@chromium.org> wrote:

Thanks for the clarification, that makes sense. Non-OWNER LGTM.

[Joe Medley]

Here's my understanding so far.

In M48:

• The flag covering code will be removed in desktop. (According to the dashboard, it's already in mobile and webview.)
• Key will be shipped, but I can't tell whether it will be behind a flag.

Joe

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

[Dave Tapuska]

Currently there are two runtime flags:

KeyboardEventCode status=experimental

KeyboardEventKey status=experimental

The intent of this change is to remove the KeyboardEventCode runtime flag. It is implemented in mobile and webview as well; and works correctly if you use a physical keyboard with the Google virtual keyboard.

Let's deal with KeyboardEvent.key on a separate Intent to Ship that will come in the future.

dave.

[Gary Kačmarčík (Кошмарчик)]

On Wed, Sep 30, 2015 at 7:42 AM, PhistucK <phis...@gmail.com> wrote:

Do you know whether Edge or Safari are going to implement this?

Microsoft is directly involved with the spec, so they are supportive. But I don't know what their timeline is for adding support. Note the 'key' values supported by IE/Edge are based on an older version of the spec, so I imagine that any work they took on would be to update the 'key' values in addition to adding 'code'.

Mozilla's implementation of 'key' and 'code' is based on the latest version of the spec.

We have no signals from Safari about either of these attributes.

[Philip Jägenstedt]

LGTM1 to ship.

Are KeyboardEvent.code and .key full replacements for .keyIndentifier? Usage of the latter is still pretty high, is simply standardizing that off the table?

[Dave Tapuska]

.key is a full replacement for .keyIdentifier

.code exposes something to the web that was never available before

Chrome and Safari are the only browsers to still to support .keyIdentifier; it has been removed from IE/Edge, and FireFox a while ago.

[Philip Jägenstedt]

OK, sounds like this is a discussion we should save for the intent to deprecate .keyIdentifier.

[Rick Byers]

LGTM2 to ship.

Please use the intent-to-ship templeate - in particular some details on the missing sections:

Compatibility risk

mostly covered by the above discussion (shipped in Firefox, Microsoft involved in the spec).

Note that status.modern.ie says work here is "not currently planned" :-(

Demo link

You may have something better, but my http://rbyers.net/eventTest.html page now includes 'code'

Debuggability

IIRC devtools existing keyboard event debugging code doesn't need any modification (eg. 'code' naturally shows up correctly in monitorEvents)

[Jochen Eisinger]

lgtm3

[PhistucK]

On Thu, Oct 1, 2015 at 6:28 PM, Rick Byers <rby...@chromium.org> wrote:

Note that status.modern.ie says work here is "not currently planned" :-(

​The specification that is linked from that entry is a different one and does not specify .code or .key.​

☆PhistucK

[Rick Byers]

Yeah that's just an old link to a specific old version of the UI Events spec that got gutted.  If you click on the "current published version link" from there you'll get this newer version of UI Events.  The entry says explicitly "identify the physical key being pressed" which I think can only refer to 'code'.

☆PhistucK

[PhistucK]

Jacob, is there any intention of updating KeyboardEvent.key to its latest specification definition as well as adding KeyboardEvent.code? I created a pull request for a status entry, just in case.

☆PhistucK

[travis....@gmail.com]

On Wednesday, September 30, 2015 at 8:52:34 AM UTC-7, Gary Kačmarčík wrote:

On Wed, Sep 30, 2015 at 7:42 AM, PhistucK <phis...@gmail.com> wrote:

Do you know whether Edge or Safari are going to implement this?

Microsoft is directly involved with the spec, so they are supportive. But I don't know what their timeline is for adding support. Note the 'key' values supported by IE/Edge are based on an older version of the spec, so I imagine that any work they took on would be to update the 'key' values in addition to adding 'code'.

We have a workitem to update our .key implementation (from circa 2010), and to add support for .code, but this workitem has not bubbled to the top of our priority list given only Firefox was adding support recently. With Chrome's new interest, this changes the priority of the work, and I realize we need to update our status page to reflect that.