Pointer Events Now in Firefox Nightly

Reminds me of the old Win 95 joke:

    ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
    ┃ You have moved the mouse pointer ┃
    ┃                                  ┃
    ┃ Windows will have to restart to  ┃
    ┃        apply this change         ┃
    ┃                                  ┃
    ┃               [OK]               ┃
    ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

Precisely. I actually don't see the point in asking the user unless regular events _also_ get disabled.

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.

That's not how polyfills work.

How about you link which xkcd [0] comic and Joel [1] blog post you're talking about rather than assuming we know.

[0] It's not capitalised

[1] Spolsky, I assume.

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.