Primary eng (and PM) emails
Link to “Intent to Deprecate” thread
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:
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
Entry on the feature dashboard
Primary eng (and PM) emails
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.)
--
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.
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.
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.
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?