Intent to Deprecate: WheelEvent.webkitDirectionInvertedFromDevice

[Philip Jägenstedt]

Primary eng (and PM) emails

phi...@opera.com

Summary

Deprecate the WheelEvent.webkitDirectionInvertedFromDevice IDL attribute.

Motivation

It always returns false.

Compatibility Risk

Low, since going from false to undefined will only affect code paths that explicitly compare with true or false, which is likely a minority of the usage. 

Alternative implementation suggestion for web developers

Assume it is false and simplify. Presumably WebKit doesn't always return false, so leaving things as they are would also work.

Usage information from UseCounter

http://www.chromestatus.com/metrics/feature/timeline/popularity/384

Available in M36. Highest usage is 0.06%. This is twice the 0.03% threshold, but in this case I'd argue the risk is lower than some removals below that threshold.

Entry on chromestatus.com, crbug.com, or MDN

None.

Requesting approval to remove too?

No, given the usage deprecation seems prudent.

[Eric Seidel]

Curious if that returns non-false in Safari.  Do we know if there is a plan to expose this via the spec?  It feels like a useful things for apps to be able to read.

lgtm regardless.

[Philip Jägenstedt]

I tried to cause a WheelEvent in Safari to check, but using the
touchpad to scroll doesn't cause wheel events it seems. If someone has
a Mac with a mouse and wants to investigate, that would be nice.

Philip

[PhistucK]

https://twitter.com/peteblois/status/258777689547231233 says it works using Safari.

☆PhistucK

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

[Ben Vanik]

Has there been any progress on standardization? I filed a bug awhile back about this property not working but it sounds like it never went anywhere: https://code.google.com/p/chromium/issues/detail?id=156551

Having a way to detect the physical wheel/gesture direction is important for any app that maps physical interaction directly to digital interaction; not all apps are using wheel events for page scroll. Games, any application implementing a wheel/gesture-based zoom (maps, etc), and art tools are all places that often want to know the real direction.

This property never worked in Chrome (sadly), but I believe that something like it is required so long as there is a world where different platforms/users have different settings. Right now guessing that someone has inverted scrolling if they are on ChromeOS or OSX is about the only thing one can do without having to explicitly ask the user. It'd be really nice to see this standardized in some way!

[Philip Jägenstedt]

The use cases for this seem reasonable, but I don't know anything
about the spec situation. Maybe Rick Byers know more?

In any event, implementing and shipping this using the prefixed name
would not be appropriate, so keeping webkitDirectionInvertedFromDevice
around doesn't seem meaningful.

Philip

[Adam Barth]

On Wed Jul 30 2014 at 7:59:06 AM Philip Jägenstedt <phi...@opera.com> wrote:

The use cases for this seem reasonable, but I don't know anything
about the spec situation. Maybe Rick Byers know more?

In any event, implementing and shipping this using the prefixed name
would not be appropriate, so keeping webkitDirectionInvertedFromDevice
around doesn't seem meaningful.

Yeah.  If webkitDirectionInvertedFromDevice returned the correct value there might be some argument for keeping it around while we work on a standards-based replacement, but given that it's always false, we should just remove it.

IMHO, we should go directly to removal because it's most likely that web sites will continue to function correctly if we remove the property.  A deprecation message isn't likely to benefit many people.

Adam

 

>>> email to blink-dev+unsubscribe@chromium.org.

>>
>>
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to blink-dev+unsubscribe@chromium.org.
>
>

[Rick Byers]

On Wed, Jul 30, 2014 at 10:59 AM, Philip Jägenstedt <phi...@opera.com> wrote:

The use cases for this seem reasonable, but I don't know anything
about the spec situation. Maybe Rick Byers know more?

I'm not aware of any active effort here.  I agree supporting such a standard API if it existed could be reasonable.  But I don't think it's at all urgent, and definitely doesn't align with our focus on mobile.

I spoke a bit to the Google maps team about this problem, and they said as far as they knew their users were happy to have the zoom semantics inverted along with the scroll direction - that users would expect an inverted direction to apply universally, and so they saw no such need for such an API.

In any event, implementing and shipping this using the prefixed name
would not be appropriate, so keeping webkitDirectionInvertedFromDevice
around doesn't seem meaningful.

Agreed.  The implementation is trivial to add again if someone eventually does the scenario justification and spec work.  I don't see a need to push on that ourselves.  Let's just remove the useless prefixed API.

[Philip Jägenstedt]

On Wed, Jul 30, 2014 at 5:13 PM, Adam Barth <aba...@chromium.org> wrote:

> IMHO, we should go directly to removal because it's most likely that web
> sites will continue to function correctly if we remove the property. A
> deprecation message isn't likely to benefit many people.

I'm happy to remove without deprecation if I get the LGTMs to do it :)

Philip

[Rick Byers]

I'm not an API owner, but I want to be clear that I support immediate removal.  Web pages are very likely to have a fallback for browsers that don't implement this API, and even if they don't (or assume Chrome will implement it) it seems incredibly unlikely that they'd treat 'false' and 'undefined' differently.

Of course in the unlikely event we find real-world examples of compat issues, then we'd probably want to add it back with a deprecation warning.

Philip

[Adam Barth]

The API OWNERS met today and approved direct removal of webkitDirectionInvertedFromDevice.  It makes sense to add some feature like this in the future, but we'll want to add it without a vendor prefix.  Because the current implementation always returns false and |undefined| is falsy in JavaScript, we will hopefully be able to remove the feature without causing much compatibility harm.

Adam