Re: Browsers, Developers and Pointer Events Meeting Notes

On Thu, Aug 28, 2014 at 5:03 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>
wrote:

>   On Thu, Aug 28, 2014 at 1:55 PM, Rick Byers <rbyers@chromium.org> wrote:
> >
> > Our primary concern with pointer events is the fragmentation problem -
> that we'd have to support two models for the foreseeable future, without
> any clear path to deprecate one with the other.  This doesn't change that.
>
>  Fairly common problem (table layout > grid/flexbox/etc) with little
> demonstrated impact in blocking browsers from moving the web forward.
>
>
>
> Since most of your proposed touch event extensions are features of pointer
> events and just about all involve API surface expansion in a similar
> fashion as pointer, how do you see the support burden as different between:
>
>
>
> (a)  Pointer Events + Touch Events
>
> (b)  Touch Events + Touch Events Extensions
>
To be clear, I'm not really worried here about the burden on browser
implementers (this issue is too important I think to nit-pick over whether
it creates more work for _us_).

It's the burden on the web developer we're concerned with.  In the scenario
we're focused on (mobile), we're in a state today where web devs can, for
the most part, write Touch Event code for one browser (eg. Safari) and have
it work on all mobile browsers (this narrow focus is, of course, a whole
other topic for potential debate).  There are still differences at the
edges of course, but we're making progress driving them down (eg. our
touchcancel on scroll difference was a constant source of confusion which
we've eliminated).

Now if a product with a lot of existing touchevent code decides they want
to address one of the shortcomings in the current model - say they want to
add some hover effect somewhere in their UI for hover capable touchscreens
or styluses.  We could give them one of the following suggestions:

1) Rewrite/duplicate all your existing Touch Event code to use Pointer
Events (but keep the Touch Event code around or use a polyfill to keep
things working on Safari).  Given how many websites still don't support
pointer events (even though it means giving up on a non-trivial portion of
potential user base), it's clear this isn't really an attractive option.

2) Try to opt-in to using pointer events for such new scenarios only, but
keep your existing touch event code for all other scenarios / browsers.
 This might be possible, but the interactions seem potentially confusing
and tricky - eg. what if one component sees touch events and not pointer
events or vice-versa due to the difference in targeting model.

3) Use a new API (when available) that is designed to integrate compatibly
and seamlessly with your existing code base.  All your code that doesn't
care about the extended functionality remains unmodified/agnostic.

#3 is what I mean by "pay for play" - developers will start using a new API
when the incremental value it provides is greater than the cost of using
it.  If the cost includes rewriting a bunch of existing code/scenarios that
were working just fine, then the value has to be MUCH larger to justify it.
 Back when our focus was "how do we get all these mouse-based websites to
better support touch on laptops and phones" Pointer Events was the perfect
choice - and I can see why it remains part of the right choice for IE's
strategic direction.  But now with a focus of "how do we get
mobile-optimized websites to compete better with their native mobile
counterparts" the alternate design is the more pragmatic one.

We know we have very little currency with today's web devs.  If I answer
some "how can I ..." question with "you should rewrite some parts of your
app to ...", there's a good chance that developer will decide to just leave
it alone and spruce up their native app instead <grin>.  The web can't
afford that.

I hope this helps explain our thinking a little better.  I don't expect
everyone to agree with it, but I do think it's important that we try to
communicate how we're really trying to do what we feel is best for the web,
and why we're willing to take the serious step of disagreeing with all of
you whose collaboration we value so much.  But now I'm putting my laptop
away and intend to enjoy my last weekend of summer (I'm saying at a resort
on a lake) without thinking about Pointer Events again until Tuesday ;-)

Rick

P.S. Back when I worked at Microsoft, Anders Hejlsberg explained this "pay
for play" argument to me in the context of programming language design (I
asked for generic variance support in C#, but at the time he didn't see how
to add it in a fully compatible way).  In my opinion, this property makes
his approach to TypeScript more pragmatic (and in my personal opinion, a
more likely way to gain wide adoption) than Google's approach to Dart.