Intent to Deprecate: KeyboardEvent.keyIdentifier

閲覧: 344 回
最初の未読メッセージにスキップ

Dave Tapuska

未読、
2016/04/27 19:19:542016/04/27
To: blink-dev

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 (Кошмарчик)

未読、
2016/04/27 21:04:362016/04/27
To: Dave Tapuska,blink-dev
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

未読、
2016/04/27 21:15:512016/04/27
To: Gary Kačmarčík (Кошмарчик),Dave Tapuska,blink-dev
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

未読、
2016/04/27 21:16:032016/04/27
To: Gary Kačmarčík,blink-dev

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

Dave

Wez

未読、
2016/04/27 21:21:092016/04/27
To: Rick Byers,Gary Kačmarčík (Кошмарчик),Dave Tapuska,blink-dev
'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

未読、
2016/04/28 12:19:282016/04/28
To: Wez,Rick Byers,Gary Kačmarčík (Кошмарчик),blink-dev

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

未読、
2016/04/28 12:57:482016/04/28
To: Wez,Rick Byers,Gary Kačmarčík (Кошмарчик),blink-dev
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

未読、
2016/04/28 13:14:242016/04/28
To: Dave Tapuska,Wez,Gary Kačmarčík (Кошмарчик),blink-dev
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

未読、
2016/04/28 13:51:442016/04/28
To: Rick Byers,Dave Tapuska,Gary Kačmarčík (Кошмарчик),blink-dev
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

未読、
2016/04/28 13:52:492016/04/28
To: Rick Byers,Dave Tapuska,Wez,Gary Kačmarčík (Кошмарчик),blink-dev
Note that the Developer Tools, the login bubble(?) and more may be using it, so eliminate in-house usage first -

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 (Кошмарчик)

未読、
2016/04/28 14:04:482016/04/28
To: PhistucK,Rick Byers,Dave Tapuska,Wez,blink-dev
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 -

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

未読、
2016/04/28 14:09:292016/04/28
To: Gary Kačmarčík (Кошмарчик),Rick Byers,Dave Tapuska,Wez,blink-dev
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

未読、
2016/04/29 5:02:162016/04/29
To: Rick Byers,Dave Tapuska,Wez,Gary Kačmarčík (Кошмарчик),blink-dev
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

未読、
2016/04/29 11:11:392016/04/29
To: Philip Jägenstedt,Rick Byers,Dave Tapuska,Wez,Gary Kačmarčík (Кошмарчик),blink-dev
LGTM3

Joe Medley

未読、
2016/09/08 18:20:292016/09/08
To: Dave Tapuska,blink-dev
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 (Кошмарчик)

未読、
2016/09/08 19:09:352016/09/08
To: Joe Medley,Dave Tapuska,blink-dev
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.

全員に返信
投稿者に返信
転送
新着メール 0 件