RE: Blink does not plan to implement pointer events

On Wed, Aug 20, 2014 at 4:23 PM, Arthur Stolyar <nekr.fabula@gmail.com> wrote:
>
> Thank you for detailed answer. As I know PointerEvents polyfills have difficulties with PointerEvents hit-testing model (for pointermove even with pointer-capture) and this is main reason why I proposed trackBoundaries: false; option. It gives legal way for polyfills to disable hit-testing on each move (instead of have their own option which 'll be not compatible with native realizations).

Indeed this is an argument for why native pointer event implementations are desirable. Similarly, polyfills can't provide the scrolling/zooming performance optimizations that native pointer event implementations can.

> Polyfills are important because WebKit absolutely (for now?) does not plan to support PointerEvents. Also, in the world there Blink 'll not support PointerEvents no one 'll need them. Libraries like Hammer 'll dominant. This situation almost here, since I heard about two surprising news: IE for Mobile implemented TouchEvents and Blink 'll not plan to implement PointerEvents.
>
> Many realizations of same user input is really hell for developers, especially for new web developers. This world looks like people still 'll develop sites for WebKit (TouchEvents) only or 'll use popular libraries like Hammer and never think about TouchEvents or PointerEvents.. or something, that 'll not matter in second case. No one 'll need those event models.
>
> I am probably now looks like a pessimist, but which world you can image with two different input models for touch? Remember about IE attachEvents and W3C addEventListener. Many years no one used polyfill for addEventListener, all used libraries like jQuery, MooTools and so on. And that is still here. Many people still need to support IE8.
>
> It's really worst idea to have PointerEvents and TouchEvents simultaneously. Do not do same mistakes as 10 years ago, please.

I'd really love to hear more about your concerns about simultaneously supporting both (we actually did this in response to web developers' requests). I'm not sure the comparison to attachEvent/addEventListener is valid.  In IE8, we only supported attachEvent while other browsers supported addEventListener. So yes, code had to write to both. But then in IE9 we supported both and we heard nothing but praise from developers.  Fastforward to IE11, we were able to remove attachEvent because code moved to the better API.  A similar comparison would be adding more sophisticated CSS layout techniques (floats, grid, flexbox, etc) side-by-side with table layout. On the web there's often "many ways to skin a cat" and developers like the flexibility of choosing the API that's best for them.

With support for both, developers can choose which API to use. There's no requirement to use both. In our minds, this should make it easier to transition to Pointer Events (like the above attachEvent/addEventListener example).  

-Jacob

Received on Thursday, 21 August 2014 00:09:26 UTC