Re: Blink does not plan to implement pointer events

>
> 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).


As I am not a native in english it looks like you missunderstood me. I
think choosed wrong word (simultaneously). I mean that it very bad idea to
have two different implementations in the web (across browser) just like
attachEvent/addEventListener. Because situation now goes to:

* Firefox plan to support both Touch and Pointer events.
* Safari (WebKit) do not plan any support of PointerEvent
* Blink does not plan to support PointerEvents, but plan upgraded
TouchEvents
* IE on desktop (Win 8 +) support PointerEvents
* IE on mobile (Win 8 +) support both Pointer and Touch events

I see fragmentation here. Like with attachEvent/addEventListener, but more
complicated.

Also, I am ok with two events models in one browser/engine. You are right,
web developers very like progress of web platform and all that you
described about side-by-side implemenations is good.

Implementation of TouchEvent in IE on mobile seems for me like a forced
move because of current dominance of WebKit. It's resonable and nothing
problems here. But in conjunction with that Blink does not plan to support
PointerEvents it's very scary. It looks like PointerEvents going to die
because if you was forced to support TouchEvents on mobile before you heard
about Blink plans, you now might be force to add TouchEvents to desktop
version, or second case there you 'll not support TouchEvents and then come
fragmenation era of touch input.

I am not argue IE to support TouchEvents. It's just very sad that Blink
refused support of PointerEvents after.. two years?



2014-08-21 3:08 GMT+03:00 Jacob Rossi <Jacob.Rossi@microsoft.com>:

> 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
>



-- 
@nekrtemplar <https://twitter.com/nekrtemplar>