5 ms·

I'm going against the grain and make the assertion that improving the Touch Events was the better option here. Touch Events are supported by more browsers and d

by pippy 12y ago

I'm going against the grain and make the assertion that improving the Touch Events was the better option here. Touch Events are supported by more browsers and devices and already have many of the functional requirements that Pointer Events have. While it makes sense to have a consistent API, for the foreseeable future there will be three event standards; touch, pointer, and mouse. While if there was focus on an existing standard it would leave web developers with a smaller room for error. A direct result of Blink using the Pointer Event standard is that there will be more web bloat such as jQuery wrappers to abstract interaction. Most web developers like have experienced the mess of getting touch events and mouse events feeling consistent across different devices and browsers. Throwing more hardware and an extra API into the mix is only going to make things worse. I welcome the much needed pressure support, for the average web developer and user the result will likely be detrimental. Colour me cynical, each browser has to nail its implementation or we're going to see another messy standard. IE for example still does not support Touch Events, even on WP. This makes front end development painful if you support the device.

rbyers 12y ago
This is a complicated set of trade offs and I've argued on both sides of the fence so I can't pretend to imply the decision is at all clear cut. But let me respond to a couple details here. First, the 'jQuery bloat' you're worried about looked like it was going to happen without Chrome native support: http://blog.jquery.com/2015/02/24/getting-on-point/ http://blog.jquery.com/2015/02/24/getting-on-point/. One of our goals in revisiting the decision was to avoid frameworks like jQuery having to include such polyfills to Chrome users. The other thing is that we shouldn't assume Chrome doing Pointer Events means we won't also improve Touch Events. That's a complicated decision influenced in large part by participation by other browser vendors in the standards process around Touch Events.
dmethvin 12y ago
> IE for example still does not support Touch Events, even on WP. Yes they do. However, IE11 doesn't support Touch Events on desktop because there is already too much code out there that makes stupid assumptions about Touch Events implying a tablet or phone without a mouse. http://blogs.msdn.com/b/ie/archive/2014/09/05/making-the-web-just-work-with-any-input.aspx http://blogs.msdn.com/b/ie/archive/2014/09/05/making-the-web...
- pippy 12y ago
  MSIE 11 for mobile is still in developer preview mode, and hasn't been released. As for the desktop version, here's caniuse:http://caniuse.com/#feat=touch http://caniuse.com/#feat=touch I'm unaware that they released a desktop version where they enabled it, I'll have to look into it.
  - gtjrossi 12y ago
    The version of IE with Touch Events (Windows Phone 8.1 Update) is no longer in preview. You can buy retail devices with it on it today, actually. For the desktop version, see my recent blog post: http://blogs.msdn.com/b/ie/archive/2015/02/24/pointer-events-w3c-recommendation-interoperable-touch-and-removing-the-dreaded-300ms-tap-delay.aspx http://blogs.msdn.com/b/ie/archive/2015/02/24/pointer-events...

by pippy 12y ago

rbyers 12y ago

This is a complicated set of trade offs and I've argued on both sides of the fence so I can't pretend to imply the decision is at all clear cut. But let me respond to a couple details here. First, the 'jQuery bloat' you're worried about looked like it was going to happen without Chrome native support: http://blog.jquery.com/2015/02/24/getting-on-point/ http://blog.jquery.com/2015/02/24/getting-on-point/. One of our goals in revisiting the decision was to avoid frameworks like jQuery having to include such polyfills to Chrome users. The other thing is that we shouldn't assume Chrome doing Pointer Events means we won't also improve Touch Events. That's a complicated decision influenced in large part by participation by other browser vendors in the standards process around Touch Events.

dmethvin 12y ago

> IE for example still does not support Touch Events, even on WP. Yes they do. However, IE11 doesn't support Touch Events on desktop because there is already too much code out there that makes stupid assumptions about Touch Events implying a tablet or phone without a mouse. http://blogs.msdn.com/b/ie/archive/2014/09/05/making-the-web-just-work-with-any-input.aspx http://blogs.msdn.com/b/ie/archive/2014/09/05/making-the-web...

pippy 12y ago
MSIE 11 for mobile is still in developer preview mode, and hasn't been released. As for the desktop version, here's caniuse:http://caniuse.com/#feat=touch http://caniuse.com/#feat=touch I'm unaware that they released a desktop version where they enabled it, I'll have to look into it.
- gtjrossi 12y ago
  The version of IE with Touch Events (Windows Phone 8.1 Update) is no longer in preview. You can buy retail devices with it on it today, actually. For the desktop version, see my recent blog post: http://blogs.msdn.com/b/ie/archive/2015/02/24/pointer-events-w3c-recommendation-interoperable-touch-and-removing-the-dreaded-300ms-tap-delay.aspx http://blogs.msdn.com/b/ie/archive/2015/02/24/pointer-events...