Intent to Implement: Pointer Events in Chrome

Post by pippy » Thu, Mar 26, 2015, 12:38 AM UTC

dmethvin wrote: post #41

pippy wrote: post #37

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

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

Post by nevir » Thu, Mar 26, 2015, 6:35 AM UTC

mbrubeck wrote: post #35

existencebox wrote: post #33

Earlier quoted context omitted.

Disclaimer: I am primarily a systems guy, and extremely green in all things web. Why wouldn't a concept of "event inheritence" be valuable here? Pointer events could be both touch or click events; and the consumer can chose due to the type specified which they want to fire on. I understand this isn't the model that events have been built under in web proper, but if I'm grokking the conflict here (there's a large chan…

DOM events do form an inheritance hierarchy. For example, TouchEvent and MouseEvent both inherit from UIEvent. But for compatibility reasons, we can't make arbitrary changes to legacy APIs. So rather than, say, change MouseEvent to be a subtype of PointerEvent, we have to do the reverse and have PointerEvent extend MouseEvent.