W3C home > Mailing lists > Public > public-pointer-events@w3.org > July to September 2014

RE: Browsers, Developers and Pointer Events Meeting Notes

From: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Wed, 3 Sep 2014 02:09:03 +0000
To: Rick Byers <rbyers@chromium.org>
CC: Arthur Stolyar <nekr.fabula@gmail.com>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Message-ID: <08848866b1e64dd0bd9a85282c2ebc66@BY2PR03MB457.namprd03.prod.outlook.com>
On Fri, Aug 29, 2014 at 7:25 PM, Rick Byers <rbyers@chromium.org> wrote:
> 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

This argument can be applied to a lot of (if not most) new standards. Again, I use the comparison with CSS layout standards. I can't imagine we'd be in a better place if we had provided attributes on table elements that allowed them to have the functionality of flexbox and grid. Developers are willing to make the move to a better API--the very existence of polyfills demonstrates this acceptance. I think if the web developer burden you suggest is real, then we wouldn't see comments like those we've seen this last couple weeks on CRBug, Reddit, HN, etc. [1] nor would there be 28k + hits for "pointerdown" in JS code on GitHub.  Furthermore, it's not every day that two of the most influential open source web framework foundations requests a 2 hour phone call with browser vendors (as in the start of this thread), let alone decide to take a hard dependency on an API at this stage in interoperability. I've really seen nothing but evidence that web developers want pointer events and are willing to make the switch now or at least once other browsers also support it.

So we want to help make this happen for web developers in an open and interoperable way. To that end, consider this an open invitation for the Chrome, Mozilla, Opera, or Safari teams to come up to Redmond and work with us further on any remaining technical issues (or we’ll come to you if that’s easier). If it helps, we’re happy to share internal design docs, architecture diagrams, testing methodologies, and even our code (seriously!).

-Jacob

Received on Wednesday, 3 September 2014 02:09:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:26 UTC