RE: 2 proposals for stylus support. Extend range of Touch.rotationAngle. Add Touch.tilt

Hi,

 

In actual implementation of the stylus, “hover” functionalities are mapped to mouse events.

 

We wanted first to focus on missing important features like “tilt”, adding it to existing TEE API, following the incremental approach (such feature might be valid also to finger in future…).

 

In my opinion, the rest is a separate issue. It is more about harmonization of mouse and touch event system. And can be discussed in separated thread (as Jacob did).

 

 

BR,

Alessandro 

 

 

 

From: Rick Byers [mailto:rbyers@google.com] 
Sent: 04 February 2015 13:07
To: Jacob Rossi; Denis Pikalov; Alessandro Cogliati
Cc: Olli Pettay; public-touchevents@w3.org
Subject: Re: 2 proposals for stylus support. Extend range of Touch.rotationAngle. Add Touch.tilt

 

 

On Tue, Feb 3, 2015 at 5:29 PM, Jacob Rossi <Jacob.Rossi@microsoft.com> wrote:



On Wed, Jan 28, 2015 at 10:12 AM, Rick Byers <rbyers@google.com> wrote:
>
> On Wed, Jan 28, 2015 at 12:26 PM, Olli Pettay <olli@pettay.fi> wrote:
>>
>> On 01/28/2015 07:11 PM, Rick Byers wrote:
>>>
>>> On Wed, Jan 28, 2015 at 11:13 AM, Olli Pettay <olli@pettay.fi <mailto:olli@pettay.fi>> wrote:
>>>
>>>     On 01/28/2015 06:01 PM, Rick Byers wrote:
>>>
>>>         Thanks Allesandro, I agree this is important.
>>>
>>>         If it helps to move this discussion forward quicker, I'd be happy to take patches for such an API in chromium behind the "experimental web
>>>         platform
>>>         APIs" flag (we wouldn't ship them enabled by default until there is an official spec somewhere).  There's some risk here, but as Denis's patch
>>>         shows
>>>         <https://codereview.chromium.__org/750013004/ <https://codereview.chromium.org/750013004/>> the implementation cost is low, so as long as
>>>         discussion is happening in W3C and we have some doc
>>>         somewhere defining the proposed API precisely, then I see no reason to block landing an experimental implementation in chromium.  We can discuss
>>>         further over on input-dev@chromium.org <mailto:input-dev@chromium.org> <mailto:input-dev@chromium.org <mailto:input-dev@chromium.org>__> if
>>>         you like.
>>>
>>>         *Jacob, *I'd love to get your input on this.  We all agreed in the conference call that there's increasing interest in stylus support.  Even
>>>         for those
>>>         that feel PointerEvents is the best way forward, adding these properties to TEE is the only clear path to getting the PointerEvents polyfill
>>>         to have
>>>         stylus support in Chromium.
>>>
>>>
>>>
>>>     Still wondering... there really isn't any way to change PointerEvents spec so that Google would be happy to implement it?
>>>     Making significant changes to Touch Events won't be in anyway more backwards compatible than Pointer Events.
>>>     (I'm really worried that we'll end up having Touch Events and Touch Events++ which won't be quite compatible, but will be hard to
>>>     feature detect the differences.)
>>>
>>>
>>> There are specific things we could nitpick over, but as I've said these are all minor compared to the fragmentation question.  Without a path to
>>> getting the API on all major browsers, I don't see how we would decide to ship PE in chromium (but as I've said before, we are keeping an open mind
>>> and watching the situation in the community - no decision is ever final).  This discussion might be most productive on a call (happy to make it the
>>> focus of a whole call if folks are interested), but since we don't have one scheduled for 3 weeks let's see how far we can get over e-mail.
>>>
>>> The fundamental difference I see between these two approaches is about the level of risk due to the size of the surface area and changes required in
>>> applications.  Eg. I don't see it as much of a problem that we have radiusX and radiusY on TouchEvent but no other browser (AFAIK) does (I've never
>>> heard someone complaint that that broke their website, or made it harder to write touch code that worked correctly across browsers).  Safari doesn't
>>> support contact area, apps can feature detect for the API on browsers that do support it, and in most cases they don't need to use the API.  Do you
>>> see our contact area support as creating a "TouchEvents++ which isn't quite compatible"?
>>
>> I wasn't talking about touch area in particular.
>
>
> Right, but is it fundamentally any different from tool position?  We can learn something from our multiple years of experience shipping contact area extensions about what we can expect if we were to ship tool position extensions.
>
>>> I see "tilt" support exactly the same as contact area - the risk for hurting platform fragmentation (at least in the mobile scenarios we're
>>> discussing) is relatively low.  The key is that for the features both Chrome and Safari support, we have an identical API (modulo a couple minor
>>> issues we should work to fix).  Developers should get "pay for play" - i.e. if they decide they want access to some additional feature (like tilt)
>>> they should be able to opt-into just that without it affecting other decisions/code in their system.  Most developers won't need/care about tilt and
>>> so will pay zero cost.  Any solution that forces a developer to pay a cost not directly related to the benefit they're trying to achieve is a
>>> non-incremental solution (eg. "to get tilt at this one single place, the input handling/routing logic in the app/framework must be extended to listen
>>> for pointer events").
>>>
>>> Sometimes the net benefit is high enough to justify non-incremental solutions, but platform designers chronically over-estimate such benefits and are
>>> always disappointed by the slow adoption in the real-world where every development cost has to be justified on it's (often short-term) merits.  Dart
>>> vs. TypeScript is a good example here where I've said Microsoft has a reasonable (incremental) path to success and Google doesn't.  The hardest part
>>> of PE for us was that when we started down the path, we all agreed the net benefit of creating something new was worth it.  By the time we had the
>>> freedom to make such a decision for ourselves (i.e. we forked blink), our priorities and the landscape had changed dramatically and it became apparent
>>> that the net benefit (compared to sticking with TE - despite it's problems) was no longer enough to justify the complexity cost in our developer story.
>>>
>>> Now if Safari came out with some different API for exposing stylus support, then I'd be concerned for exactly the fragmentation reasons you mention.
>>> As best as I've been able to determine, this is unlikely to happen.
>>>
>>> What do you mean "hard to feature detect the difference"?
>>
>>
>> In general it is easier to check if API foo is supported than to check whether version x.y.z is supported.
>
>
> I agree API versions are a problem.  I don't see this as an API version - I see it as small/targeted new APIs on top of an existing API.
>
>>
>> Adding hacks over hacks in case of TE may lead to lots of tiny bit different kinds of implementations.
>> PE would give a clean start and support initially more use cases than TE.
>
>
> I'd argue the "clean start" and "more use cases" are separable - orthogonal problems.  We can achieve the use cases without the clean start as easily (I'd argue more easily) than with it.  The cost/benefit of a clean start can be evaluated on it's own merits (eg. Jacob's argument about starting standards-first rather than trying to retro-spec really resonates with me and was a big part of our interest in PE).  In IE's case (and Chrome's original case) of trying to extend the desktop browsing model with touch/stylus it certainly seems worth it.  In the case of trying to improve the web we've had for years on mobile devices (the blink team's priority), it does not appear to us to justify the platform complexity cost.
>



I'll try to avoid the "can't we just do pointer events since we already defined it there?" argument since I think everyone in this group knows where I stand on that. :-)

To truly add pen to the web platform, it's not as simple as tacking on the additional pen related properties like tilt. For example, a key component to pen support is hover, which touch events does not have a concept of.  Adding pen would require many changes that aren't really incremental:

 

Denis / Alessandro, can you provide any data on the concrete scenarios you're trying to enable here?  Eg. how important is hover or button states to the art scenarios you described? 

 

* a new event for move when hovering ***

 

Yes, and I agree this should be a new event type (as I described here <https://docs.google.com/a/chromium.org/document/d/1x-yE4CmTZlZQXea4_FPjgly5TOvF28UBNs9gZ5aGUhg/edit#heading=h.yzcxpkuboqtg> ).  Since touchmove doesn't cause a hit-test, I'd want to handle the hover and drag cases separately - allowing apps to indicate their intent to handle dragging without also appearing to require hover events.

 

Note that chromium currently fires mousemove for this for compatibility - but it would certainly be cleaner if we had, eg, 'touchhover'.  Not sure how important that really is though.

 

* events for transitioning from hovering to not hovering (down/up)

 

Isn't that just touchstart / touchend?

 

* likely new transition events (over/out/enter/leave) as this is how other hover capable devices work today because it is important for user confidence in targeting UI while hovering
* properties for pen button states, tilt, etc.

*** Note that because we're not starting clean, it's not compatibly possible to just tack on a button/buttons property to distinguish from hover/in-contact (like pointer events does) as existing touchmove handlers would be triggered as you hover your pen.

That no longer is incremental (and, yes, starts to look a lot like pointer events).  Not only is it not incremental to the API, it's also not likely to be incremental to existing touch event handling code.

 

Can you elaborate on this?  Why should existing touch handling code be confused by such extensions?  We've had exactly the opposite experience in Android where the MotionEvent API was designed for touch and Samsung added stylus support  without affecting existing apps expecting touch.  What's fundamentally different about the situation on the web?

 

So the traditional arguments for trying to extend touch events don't really resonate well with me here (add on the fact that Safari isn't likely to implement). That said, a new pen-specific event model spec would be far worse (I think we all agree that).


-Jacob