┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ You have moved the mouse pointer ┃
┃ ┃
┃ Windows will have to restart to ┃
┃ apply this change ┃
┃ ┃
┃ [OK] ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
I often wonder if browser vendors, or anybody really, believes that this sort of thing makes our world better.
All it does is add a third case that every application needs to support from here on out. You need to do your sniffing, then register mouse events or touch events or pointer events as necessary. And write similar but different code paths for each case. And you need to maintain and test all three of those branches for ever.
It's that XKCD comic. And that Joel blog post from fifteen years ago. Implemented with no irony whatsoever by people who seem not to have read either.
This spec is almost a copy of the existing APIs but with some additions, which in my experience they were very needed. The old APIs won't stop working. If you don't want several code paths use either the old APIs or pointer events with polyfill.
IMHO, the most important changes are pen support and the "touch-action" CSS property[1].
There have been many attempts to make native-looking HTML5 apps in phones and tablets. Do you know why none feel native? Scrolling. When you scroll, pan, zoom... JS events must fire and many things must happen before redrawing the screen. That's avoided with the "touch-action" property. There are other reasons but this has been the most important one.
[1] I would have preferred a HTML attribute, but things like "pointer-events" already exist.
The pointer API is significantly easier to use for non-trivial interfaces so yeah it does make the world better. For now, yes you need to worry about all 3 API sets (or use a pointer polyfill that tries to do that for you). As older browsers phase out, you'll be able to switch to only working with pointer events. Same with any other new browser API - not super useful on day 1 but eventually there is enough adoption that we can rely on it.
> All it does is add a third case that every application needs to support from here on out. You need to do your sniffing, then register mouse events or touch events or pointer events as necessary. And write similar but different code paths for each case. And you need to maintain and test all three of those branches for ever.
Joel's article is barely relevant now. The main problem has been layout discrepancies, and the pages were made for IE+others back then. Nowadays it's very difficult to step on something not properly supported in your target browsers (except if your target includes old versions of IE). I develop exclusively on Chrome with a lot of fancy HTML5 stuff and very rarely I have to tweak something for Firefox, IE11, Safari, Opera...
It's a completely different scenario than when I did web dev in 2008. Also, Joel article is not fifteen years old, it's nine.
Sounds like you're not pushing things as much as you used to in '08. The situation is no different today than it was in 1996 when I started this ride. There are sections of my current codebase that switch for iOS 4, 6, 7, 8+, android and desktop Chrome, working around idiosyncracies of each.
There's also IE, Firefox and "am I running from the local filesystem" checks in there. All necessary to work around real differences in implementation in the most current crop of "modern" browsers.
It's a rare feature that I can ship that works out of the box in every browser. But, as it was 20 years ago, this is the job we signed up for. I just wish people stopped going out of their way to add more unnecessary things that I need to special case around.
As a side note, new versions of iOS get adopted extremely fast. It's unlikely you need to maintain code to support more than a single version of iOS back. https://developer.apple.com/support/app-store/
I'm apparently a bit outdated, but it seems that Chrome is also now planning on implementing pointer events [0] after saying they wouldn't. Does anyone know if webkit has budged on their stance?
I really don't like the idea of a common pointer event.
Mouse interaction and touch interaction are as different as mouse interaction and keyboard interaction. They really do need to be treated completely differently, with different user experience models and code paths.
What makes you think this is limited to only mouse vs touch? By design the HTML+CSS+DOM platform only provides an abstraction that may or may not have a meaningful mapping to the actual interface of the User Agent.
You really shouldn't be assuming you know anything about the interface and only use pointer events in the most minimal, generic way possible. To that end, this new "pointer event" may be useful. If you want better, more detailed pointer information, you should use a platform that provides it such as writing a native app.
/* the same goes for reimplementing widgets like scrollbars: don't, that's the job of the User Agent */
It's a common interface, but you can still distinguish which of multiple devices triggered the event (with pointerId) and distinguish what type of device it was (with pointerType, which can have values "pen", "touch" or "mouse").
For some applications you'll be absolutely correct, but there are also applications where they do the exact same thing. Consider the case of panning a map, for example.
My understanding is that this is in addition to the existing mouse & touch APIs, so developers can just use whatever makes sense for their application.
"The page at xxxxx would like to track the movements of your mouse pointer. Do you wish to allow this action?"
I wonder how many pages are doing this already without their users noticing...