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
>