Intent to Remove: KeyboardEvent.prototype.keyLocation

Philip Jägenstedt

unread,

Dec 14, 2015, 8:36:12 AM12/14/15

to blink-dev

Primary eng (and PM) emails

phi...@opera.com

Link to “Intent to Deprecate” thread

This was deprecated in July 2013, before the current process.

Summary

The location attribute allows disambiguating between keys that are on multiple places on a keyboard, like digits and Enter. See the spec for details. The keyLocation is a simple alias of location, which I would like to remove.

Because this has been deprecated for a long time, people may no longer take the deprecation message seriously. I propose to update the deprecation message in M49 to include "will be removed in M50, around April 2016" and to then remove in M50.

Motivation

As the spec says "The KeyboardEvent interface was briefly (from 2003-2010) defined to have keyIdentifier and keyLocation attributes, but these were removed in favor of the current key and location attributes. These attributes were not widely implemented." (This stretches the definition of "brief" by quite a bit...)

Neither Edge nor Gecko support keyLocation, while both support location.

Also, web developers have to do extra work to avoid this deprecation message, see below.

Compatibility Risk

I have analyzed all occurrences in the 20150101 httparchive data, finding hits in 3989 resources out of about 1 million. (One page can use many resources, but I haven't counted unique pages.)

I found not a single problematic case, but many interesting things:

video.js, with 2660 hits. It has a fixEvent method that enumerates attributes, with code specifically to avoid deprecation messages!
GumGum, an ad platform with 998 hits. From the minified code, it looks like it's just listing attributes on various event types, for the purpose of eventually copying events. Nothing specific is done with keyLocation.
TinyMCE, with 180 hits, which also blacklists attributes in order to avoid deprecation messages.
A script usually called ace.js, with 44 hits, with the check `if (e.keyLocation || e.location == 3)`. This looks like a typo, it should probably check if either attribute is 3. Fortunately, it's only checked for keyCode 13 which is "Enter", where 0 and 3 are the only possible values in my testing.

The categories get smaller, and the only other thing worthy of mention is that webcomponents.js also blacklists keyLocation, presumably because of the deprecation message.

It looks like the true risk is far smaller than the use counter would suggest.

(Going forward, we should be very careful about adding deprecation messages for attributes on event interfaces.)

Alternative implementation suggestion for web developers

Use the location attribute.

Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/91

OWP launch tracking bug

https://crbug.com/568261

Entry on the feature dashboard

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

Rick Byers

unread,

Dec 14, 2015, 11:53:02 AM12/14/15

to Philip Jägenstedt, blink-dev

LGTM1. Thanks for the detailed httparchive analysis!

On Mon, Dec 14, 2015 at 8:36 AM, Philip Jägenstedt <phi...@opera.com> wrote:

Primary eng (and PM) emails
phi...@opera.com

Link to “Intent to Deprecate” thread
This was deprecated in July 2013, before the current process.

Summary
The location attribute allows disambiguating between keys that are on multiple places on a keyboard, like digits and Enter. See the spec for details. The keyLocation is a simple alias of location, which I would like to remove.

Because this has been deprecated for a long time, people may no longer take the deprecation message seriously. I propose to update the deprecation message in M49 to include "will be removed in M50, around April 2016" and to then remove in M50.

Motivation
As the spec says "The KeyboardEvent interface was briefly (from 2003-2010) defined to have keyIdentifier and keyLocation attributes, but these were removed in favor of the current key and location attributes. These attributes were not widely implemented." (This stretches the definition of "brief" by quite a bit...)

Neither Edge nor Gecko support keyLocation, while both support location.

Also, web developers have to do extra work to avoid this deprecation message, see below.

Compatibility Risk
I have analyzed all occurrences in the 20150101 httparchive data, finding hits in 3989 resources out of about 1 million. (One page can use many resources, but I haven't counted unique pages.)

I found not a single problematic case, but many interesting things:
video.js, with 2660 hits. It has a fixEvent method that enumerates attributes, with code specifically to avoid deprecation messages!
GumGum, an ad platform with 998 hits. From the minified code, it looks like it's just listing attributes on various event types, for the purpose of eventually copying events. Nothing specific is done with keyLocation.
TinyMCE, with 180 hits, which also blacklists attributes in order to avoid deprecation messages.
A script usually called ace.js, with 44 hits, with the check `if (e.keyLocation || e.location == 3)`. This looks like a typo, it should probably check if either attribute is 3. Fortunately, it's only checked for keyCode 13 which is "Enter", where 0 and 3 are the only possible values in my testing.
The categories get smaller, and the only other thing worthy of mention is that webcomponents.js also blacklists keyLocation, presumably because of the deprecation message.

It looks like the true risk is far smaller than the use counter would suggest.

(Going forward, we should be very careful about adding deprecation messages for attributes on event interfaces.)

+1. It's tempting to say there's no point in adding the deprecation warning at all, yet as we've seen in other recent threads developers do sometimes rely on these messages.

It's also tempting to think that this data is a sign we should add an API that let's JavaScript ask if a specific API is deprecated (so it could be automatically skipped in such copy code). But that would run the risk of causing a chicken-and-egg problem where we can't even deprecate an API without breaking sites. Maybe that's OK though, since we don't (at least currently) expect deprecation itself to have much impact on usage.

Chris Harrelson

unread,

Dec 14, 2015, 12:38:01 PM12/14/15

to Rick Byers, Philip Jägenstedt, blink-dev

LGTM2

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

Dimitri Glazkov

unread,

Dec 14, 2015, 12:38:47 PM12/14/15

to Chris Harrelson, Rick Byers, Philip Jägenstedt, blink-dev

LGMT3

Dave Tapuska

unread,

Dec 14, 2015, 1:01:08 PM12/14/15

to Dimitri Glazkov, Chris Harrelson, Rick Byers, Philip Jägenstedt, blink-dev

Thanks Phillip for taking action on this one. It's good to get this cleaned up.

Philip Jägenstedt

unread,

Dec 14, 2015, 2:00:48 PM12/14/15

to Rick Byers, blink-dev

On Mon, Dec 14, 2015 at 5:52 PM, Rick Byers <rby...@chromium.org> wrote:

On Mon, Dec 14, 2015 at 8:36 AM, Philip Jägenstedt <phi...@opera.com> wrote:

(Going forward, we should be very careful about adding deprecation messages for attributes on event interfaces.)

+1. It's tempting to say there's no point in adding the deprecation warning at all, yet as we've seen in other recent threads developers do sometimes rely on these messages.

Skipping deprecation entirely because it can be hit by enumeration may be going too far, but I think we should think twice before deprecating attributes on at least Window and Event for more than a release cycle or two. For any long-lived deprecation on at least Event, I assume that video.js and others will do work to avoid it, which seems sad if they would otherwise never even know about the deprecated attribute.

It's also tempting to think that this data is a sign we should add an API that let's JavaScript ask if a specific API is deprecated (so it could be automatically skipped in such copy code). But that would run the risk of causing a chicken-and-egg problem where we can't even deprecate an API without breaking sites. Maybe that's OK though, since we don't (at least currently) expect deprecation itself to have much impact on usage.

An interesting idea, but other than deprecations done via IDL, it seems hard to generalize. Do you understand why people are enumerating event attributes at all? Is it an Event.prototype.clone() they really want?

With an API for collecting deprecation messages in the wild, maybe the issue of suppressions will resurface.

Philip

Rick Byers

unread,

Dec 14, 2015, 2:48:10 PM12/14/15

to Philip Jägenstedt, blink-dev

On Mon, Dec 14, 2015 at 2:00 PM, Philip Jägenstedt <phi...@opera.com> wrote:

On Mon, Dec 14, 2015 at 5:52 PM, Rick Byers <rby...@chromium.org> wrote:

On Mon, Dec 14, 2015 at 8:36 AM, Philip Jägenstedt <phi...@opera.com> wrote:

(Going forward, we should be very careful about adding deprecation messages for attributes on event interfaces.)

+1. It's tempting to say there's no point in adding the deprecation warning at all, yet as we've seen in other recent threads developers do sometimes rely on these messages.

Skipping deprecation entirely because it can be hit by enumeration may be going too far, but I think we should think twice before deprecating attributes on at least Window and Event for more than a release cycle or two. For any long-lived deprecation on at least Event, I assume that video.js and others will do work to avoid it, which seems sad if they would otherwise never even know about the deprecated attribute.

Yeah. Trying to keep such warnings limited is a good balance. Presumably the warning is useful to folks like video.js too - it gives them time to try excluding the property and verify that nothing breaks when they do so. So maybe we shouldn't see it as a bad thing at all that a bunch of libraries have written such blacklists. Sure a whitelist of properties they want seems better, but probably the safe effect in the end.

It's also tempting to think that this data is a sign we should add an API that let's JavaScript ask if a specific API is deprecated (so it could be automatically skipped in such copy code). But that would run the risk of causing a chicken-and-egg problem where we can't even deprecate an API without breaking sites. Maybe that's OK though, since we don't (at least currently) expect deprecation itself to have much impact on usage.

An interesting idea, but other than deprecations done via IDL, it seems hard to generalize. Do you understand why people are enumerating event attributes at all? Is it an Event.prototype.clone() they really want?

I don't have a good understanding of this, no. Lots of event abstracting frameworks I've seen just stash the original event somewhere on their custom object. I don't know what additional value there is to actually copying the object. Maybe this is to work around issues in some browsers that modify the event object after the fact (eg. mobile Safari mutates the 'Touch' objects rather than create new ones on each event)?

houman...@gmail.com

unread,

Jun 7, 2016, 9:07:48 PM6/7/16

to blink-dev

Houman Bahrami

unread,

Jul 25, 2016, 8:26:48 PM7/25/16

to blink-dev

Sent from my iPhone

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/lqknEaUYCJM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.