Intent to Deprecate: KeyboardEvent.keyIdentifier

[Dave Tapuska]

Primary eng (and PM) emails

dtap...@chromium.org

Summary

Mark the field keyIdentifier on KeyboardEvent.idl as deprecated.

Motivation

There is a standardized KeyboardEvent.key which other vendors implement. Deprecating the feature is desired to drive adoption of the newly available key field.

Compatibility Risk

Edge, and FireFox do not implement this field so web developers have had to work around the issue for some time.

Alternative implementation suggestion for web developers

Use KeyboardEvent.key

Usage information from UseCounter

The use counter is relatively high with 0.2155%. But I do believe this usage value is inflated due to cloning of all fields in Events by delegation frameworks.

https://www.chromestatus.com/metrics/feature/popularity#V8KeyboardEvent_KeyIdentifier_AttributeGetter

OWP launch tracking bug

crbug.com/607349

Entry on the feature dashboard

https://www.chromestatus.com/features/5316065118650368

Requesting approval to remove too?

No. Ideally since this has been around for a while; I'd like to give probably 4 releases to fully deprecate it. So probably M56. But ideally the motivation of doing this is to call out the usage of KeyboardEvent.key instead.

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

LGTM! (although I'm not sure if my vote here has any weight)

This attribute was briefly part of the DOM3 Events (now UIEvents) spec, but was only implemented in WebKit.  It was removed from the spec in 2010. The last version of the DOM3 spec that mentions `keyIdentifier` is from 2009: https://www.w3.org/TR/2009/WD-DOM-Level-3-Events-20090908/

On a side note: Are there plans to deprecate `char` as well from the KeyboardEvent?

--
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.

[Rick Byers]

I've love to see us get rid of this API, but given that the vast majority of usage likely comes from libraries which do event cloning, I worry that a long deprecation period (or perhaps a warning at all) will do more harm (warning spam) than good (actually leading to reduced usage).

Can you try doing an HTTP Archive search for this to see what coding patterns are most common and get an idea of how specific sites would be impacted by removal in practice?  Other browsers have supported 'key' for awhile, right?  So hopefully most usage is guarded by code that will work as long as either 'keyIdentifier' or 'key' is present.  If we can get some alternate evidence that removal is likely to be very safe, then perhaps we can try for removal after a single deprecation milestone?

[Dave Tapuska]

From my understanding Chromium does not implement KeyboardEvent.char. So I'll be your hero and remove it :-)

Dave

[Wez]

'key' and 'keyIdentifier' are not equivalent, so I'd be surprised if there's a lot of code out there that checks for one and falls-back to the other. Given the way it was specified, though, I'd also be surprised to find anything much using keyIdentifier at all.

[Dave Tapuska]

Here is some analysis. From http archive 4676 resources were loaded that contain the keyword 'keyIdentifier'.

44% closure library:

https://github.com/google/closure-library/blob/9546e0fa38ef57fa16ecb958244149c680819bcc/closure/goog/events/keyhandler.js#L420

Chromium should fall into the first case so keyIdentifier won’t be queried.

35% bean js library cloning objects (primarily in gumgum’s ad network code)

https://github.com/fat/bean/blob/0cc7083a8986ca5be15aed721a36579c3adece69/src/bean.js#L104

2.2% AjaxControlToolkit

https://github.com/DevExpress/AjaxControlToolkit/

Not necessary; we generate compatible charCodes.

https://github.com/DevExpress/AjaxControlToolkit/blob/6c99014ea33808636a9f8c3c579e99bc6121bd75/AjaxControlToolkit/Scripts/MaskedEdit.js

Shouldn’t be a concern here; only key that would be permitted into this code path that wasn’t previously should be the Enter key. But the IE, FF code paths allow that key so in fact it should be better.

https://github.com/DevExpress/AjaxControlToolkit/blob/6c99014ea33808636a9f8c3c579e99bc6121bd75/AjaxControlToolkit/Scripts/FilteredTextBox.js

Some old version of dojo (found on a few sites)

Will execute for Chrome because we do put Safari in our user agent string. But will be fine with undefined keyIdentifier

http://www.dhl.hu/js/lib/dojo/dojo.js

False reports

Angular.js - just a variable name that has no bearing to KeyEvent

https://github.com/angular/angular.js/blob/fa79eaa816aa27c6d1b3c084b8372f9c17c8d5a3/src/ng/directive/ngRepeat.js

JQuery-Number - commented out

https://github.com/customd/jquery-number/blob/a502e75a0928b56872c58b37140dce4a5c532a78/jquery.number.js

[Dave Tapuska]

So I should have added a summary; I think based on this data I think it would be quite easy to remove these without any compatibility concerns. As most of the code written was do deal with Safari on Windows providing charCodes of 0 which Chromium does do.

dave.

[Rick Byers]

So you're saying that based on this analysis you can't find a single site in the Alexa top 500K which is likely to break with this removed, right? 

I think that, plus the lack of support in Edge and Firefox, is enough to justify giving removal a try.  So LGTM1 to remove.

The only remaining question I have is should we:

1. Deprecate for one milestone then remove:
   might give some warning to someone depending on this API (but we know in practice this doesn't have a big effect on usage).  At least shows that we did our best to warn people about the removal.
   
   
2. Remove immediately:
   avoids a bunch of unnecessary warning spam for the common case of event cloning, and wasting developer time adding `keyIdentifier` to the list of properties to skip.

I guess I have a small preference for #1 personally (as long as it's only a single milestone).  Others?

[Wez]

I'd go with #1 for a single milestone. It's a shame that frameworks end up making it so hard to get accurate stats, though.

[PhistucK]

Note that the Developer Tools, the login bubble(?) and more may be using it, so eliminate in-house usage first -

https://code.google.com/p/chromium/codesearch#search/&q=keyIdentifier%20lang:js&sq=package:chromium&type=cs

For what it is worth, I used keyIdentifier in order to identify keys on a Nokia phone (a phone with actual tone keys, yes). Many non-tone keys on that phone shared the same keyCode and keyIdentifier was the only way to identifier its equivalent of Enter.

☆PhistucK

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

On Thu, Apr 28, 2016 at 10:52 AM, PhistucK <phis...@gmail.com> wrote:

Note that the Developer Tools, the login bubble(?) and more may be using it, so eliminate in-house usage first -

https://code.google.com/p/chromium/codesearch#search/&q=keyIdentifier%20lang:js&sq=package:chromium&type=cs

For what it is worth, I used keyIdentifier in order to identify keys on a Nokia phone (a phone with actual tone keys, yes). Many non-tone keys on that phone shared the same keyCode and keyIdentifier was the only way to identifier its equivalent of Enter.

If you cannot get the information that you need from the KeyboardEvent.code and/or KeyboardEvent.key attributes, *please* let me know (or file an issue on https://github.com/w3c/uievents).

[PhistucK]

I surely will not, since that browser does not have this API, nor will it ever be updated. :)

But if a normal device or modern browser do not get me that information, I will let you know. :)

☆PhistucK

[Philip Jägenstedt]

LGTM2 to deprecate for one milestone then remove (#1)

For some other attribute I researched I found workarounds to avoid deprecation messages, but those were for a long-lived deprecation message. Hopefully if it's only for a single milestone, not many will bother (and have their time wasted).

[Chris Harrelson]

LGTM3

[Joe Medley]

I'm writing a notice about this for this page. Does anyone know what the alternative is for Safari?

Joe

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

If an API's not documented it doesn't exist.

On Wed, Apr 27, 2016 at 4:19 PM, 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+unsubscribe@chromium.org.

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

We haven't heard anything from Apple regarding updating WebKit to use |code| and |key|, so they don't have a non-deprecated alternative.

We'll hopefully learn more about their plans during TPAC (later this month), but for now Safari users need to fall back to the (also deprecated) |keyCode| and |charCode| attributes. But as mentioned earlier, this attribute was never widely implemented and was only included in the standard for a very short period of time.

[Lorand Zudor]

Hi All,

Despite the fact that the given thread is from 2016 I think there's still a scenario which can be resolved only using deprecated properties (KeyboardEvent.keyCode or UIEvent.which).

Consider the following scenario:

- there is a given shortcut in a web app mapped for Control+Alt+Z (alternatively Command+Option+Z for MacOs)

- let's also assume the user is having a qwertz keyboard layout set

- on Mac, once Command+Option+Z is pressed, one can detect the right combination only by using keyCode, since:

-- event.keyCode will be 90 (ASCII for "Z")
-- event.code takes "KeyY" (physical key)
-- event.key will be "Ź" (ASCII: 377); on default ABC layout is "Ω", so that wouldn't work, either

Best,

- Lorand.

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

--
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.

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

This is the kind of issue that KeyboardMap (https://wicg.github.io/keyboard-map/) is meant to address.

`keyCode` is not well defined, so once you get outside the common keys you see implementation differences between browsers and OSs. So there is no real path to creating a specification for it. Hence it is deprecated because it is not reliable.

Also, this issue is about `keyIdentifier`, which Safari briefly supported. As of today, Safari supports `key` and `code`, so the concerns about not having a fallback for `keyIdentifier` are no longer relevant.

-Gary

[Lorand Zudor]

Hi There,

Thanks for the explanation & for the quick response!

Facing now 2 issues:

1.) KeyboardMap is not supported on Safari (according to MDN)

2.) Does not work as supposed to (?)

Having a QWERTZ keyboard layout, once I press "y" (which is KeyZ), sending event.code received ("KeyZ") to keyboardLayoutMap.get returns "z", instead of "y":

A KeyboardLayoutMap instance is a read-only Map-like object, in which each key is a string identifying the unique physical key on the keyboard (a "key code"), and the corresponding value is the associated key attribute value (which may be affected by the keyboard layout, and so on).

See attached test script, just in case.
I still think a feature (part, component, element, method or property + etc) should not be deprecated without another (standard) one using which one can achieve the same goals (ideally in a better & quicker way..).

Best,

- Lorand.