Intent to Implement: extend TouchEvents with properties Touch.tilt and Touch.tiltDirection

[d.pi...@partner.samsung.com]

Contact emails

a.cog...@samsung.com, d.pi...@partner.samsung.com

Spec

None. There’s still active discussion at public-to...@w3.org: 

https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0110.html

 

Summary

Touch.tilt is an angle, in range [0..90] degrees, of the stylus away from the perpendicular to the screen. 

Touch.tiltDirection (similar to Android's MotionEvent) is an clockwise angle in relation to the vertical axis of the current orientation of the screen (0Y). The angle indicates the direction in which the stylus  is pointing. TiltDirection defined in range [0..360) degrees.

Motivation

Expose stylus details to web applications. We believe that new interaction models, e.g. Stylus, should be an extension of existing API and not new standalone specifications. 

Compatibility Risk

Low. This API provides new functionality and it should not break existing behaviors.

Ongoing technical constraints

Platform support. Currently, tilt and pointer's orientation are supported by Android 4.0+ (Note4 + SPen) at least

OWP launch tracking bug?

None. Related to the crbug.com/393462

 

Link to entry on the feature dashboard ?

None, will be implemented behind a 'experimental-web-platform-features' flag

 

Requesting simultaneous permission to ship?

No

[Elliott Sprehn]

Do other platforms support things like this like iOS, Chrome OS or Windows tablets?

[a.cog...@samsung.com]

Hi Elliott,

 

please check the discussion in:

https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0114.html

 

BR,

Alessandro 

[Philip Jägenstedt]

Hi Denis,

Are these the Andoid APIs underlying tilt and tiltDirection respectively?
http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_TILT
http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_ORIENTATION

Android can explicitly distinguish finger from styles using
TOOL_TYPE_STYLUS, would there be any way with this API to tell a touch
event from a stylus held perpendicular to the screen?

Also, is there any difference to Touch.webkitRotationAngle?

Philip

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

[Denis Pikalov]

Hi Philip,

Are these the Andoid APIs underlying tilt and tiltDirection respectively?
http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_TILT
http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_ORIENTATION

Android can explicitly distinguish finger from styles using
TOOL_TYPE_STYLUS, would there be any way with this API to tell a touch
event from a stylus held perpendicular to the screen?

Right. Currently it doesn't make difference between stylus and finger, so tilt=0 may means both - the Tilt is not supported (e.g. finger) OR pointer is perpendicular to the screen.

I think we could make Touch.tilt 'nullable' (null=not supported) to differentiate those cases.

 

Also, is there any difference to Touch.webkitRotationAngle?

Yes, angle range (90 vs 360 degrees) and the basis for angle (not defined for Touch.rotationAngle), please see also https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0105.html

--

Denis

[Rick Byers]

As I said in the public-touchevents thread, I support landing an experimental implementation in blink to help further the discussion about how to expose stylus devices to the web in chromium.

However, the idea is still contentious (eg. a reasonable argument can be made that pointer events is a better path forward).  When we made the decision not to support pointer events, the consensus of blink leaders was that incrementally adding capabilities to TouchEvents exactly like this  (see full design sketch) was the better path for us.

Of course we should not make any decision to ship these properties lightly.  I'm continuing to drive discussion in the touch events community group, and I'm hopeful that group will reach a consensus to formally specify these properties.

Rick

On Sun, Feb 1, 2015 at 4:25 PM, Denis Pikalov <d.pi...@partner.samsung.com> wrote:

Hi Philip,

Are these the Andoid APIs underlying tilt and tiltDirection respectively?
http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_TILT
http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_ORIENTATION

Android can explicitly distinguish finger from styles using
TOOL_TYPE_STYLUS, would there be any way with this API to tell a touch
event from a stylus held perpendicular to the screen?

Right. Currently it doesn't make difference between stylus and finger, so tilt=0 may means both - the Tilt is not supported (e.g. finger) OR pointer is perpendicular to the screen.

I think we could make Touch.tilt 'nullable' (null=not supported) to differentiate those cases.

Independently we're having a discussion on www-dom about a UIEvent.sourceDevice property which could provide details of the input device generating an event.   Lots of details to work out (eg. do we want to try to define "a stylus" or just report properties like "fine pointer, hover capable, supports tilt, etc.).  But personally I think an API like this (similar to Android's InputDevice) is the right way to address such questions.

[Philip Jägenstedt]

On Mon, Feb 2, 2015 at 4:25 AM, Denis Pikalov
<d.pi...@partner.samsung.com> wrote:
> Hi Philip,
>
>> Are these the Andoid APIs underlying tilt and tiltDirection respectively?
>>
>> http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_TILT
>>
>> http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_ORIENTATION
>>
>>
>> Android can explicitly distinguish finger from styles using
>> TOOL_TYPE_STYLUS, would there be any way with this API to tell a touch
>> event from a stylus held perpendicular to the screen?
>
>
> Right. Currently it doesn't make difference between stylus and finger, so
> tilt=0 may means both - the Tilt is not supported (e.g. finger) OR pointer
> is perpendicular to the screen.
> I think we could make Touch.tilt 'nullable' (null=not supported) to
> differentiate those cases.

This sounds like a problem that should be addressed somehow before
shipping so that people don't have to write heuristics that fail in a
corner case, but a separate property seems like the the likely
solution.

>> Also, is there any difference to Touch.webkitRotationAngle?
>
>
> Yes, angle range (90 vs 360 degrees) and the basis for angle (not defined
> for Touch.rotationAngle), please see also
> https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0105.html

I'm not sure I understand without some illustration. In terms of the
underlying Android API, would both Touch.webkitRotationAngle and
Touch. tiltDirection come from the same source, just transformed
slightly differently?

Philip

[Denis Pikalov]

> Right. Currently it doesn't make difference between stylus and finger, so
> tilt=0 may means both - the Tilt is not supported (e.g. finger) OR pointer
> is perpendicular to the screen.
> I think we could make Touch.tilt 'nullable' (null=not supported) to
> differentiate those cases.

This sounds like a problem that should be addressed somehow before
shipping so that people don't have to write heuristics that fail in a
corner case, but a separate property seems like the the likely
solution.

I guess it's reasonable to return nothing, if feature is not supported, but having separate property brings bit more complexity.

 

> Yes, angle range (90 vs 360 degrees) and the basis for angle (not defined
> for Touch.rotationAngle), please see also
> https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0105.html

I'm not sure I understand without some illustration. In terms of the
underlying Android API, would both Touch.webkitRotationAngle and
Touch. tiltDirection come from the same source, just transformed
slightly differently?

Right. Both comes from the same source, some arguments to keep them separate:

https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0098.html

--

Denis

 

[Philip Rogers]

LGTM to implement.

[Philip Jägenstedt]

On Tue, Feb 3, 2015 at 5:57 PM, Denis Pikalov
<d.pi...@partner.samsung.com> wrote:
>>
>> > Right. Currently it doesn't make difference between stylus and finger, so
>> > tilt=0 may means both - the Tilt is not supported (e.g. finger) OR pointer
>> > is perpendicular to the screen.
>> > I think we could make Touch.tilt 'nullable' (null=not supported) to
>> > differentiate those cases.
>>
>> This sounds like a problem that should be addressed somehow before
>> shipping so that people don't have to write heuristics that fail in a
>> corner case, but a separate property seems like the the likely
>> solution.
>
>
> I guess it's reasonable to return nothing, if feature is not supported, but having separate property brings bit more complexity.

It does, but let's revisit this issue when closer to shipping. Since
there's no spec yet we'll also have to take a much closer look at spec
compliance at that time.

>> > Yes, angle range (90 vs 360 degrees) and the basis for angle (not defined
>> > for Touch.rotationAngle), please see also
>> > https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0105.html
>>
>> I'm not sure I understand without some illustration. In terms of the
>> underlying Android API, would both Touch.webkitRotationAngle and
>> Touch. tiltDirection come from the same source, just transformed
>> slightly differently?
>>
>
> Right. Both comes from the same source, some arguments to keep them separate:
> https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0098.html

Thanks Denis, it sounds like rotationAngle cannot easily be changed to
fill this new role. Once implemented it will be easier to see how they
differ too.

LGTM to implement.

Philip

[Rick Byers]

We could have shoe horned rotationAngle into this, but the argument was that the semantics are different enough that it seemed likely to cause more trouble than benefit.  This is most evident in the Android API by the conditional documentation (if the tool is a stylus then the range is ...).  I reached out to the Android framework team here to ask about the history - if they thought combining the two use cases in one API was good or bad for developers, but they replied only that they had no data :-(. 

LGTM to implement.

Philip