[rbyers]

I think there is a valid concern here. But what we're seeing in practice from many major frameworks and apps is that they're unifying events anyway and special-casing the device type when needed for a great experience. Pointer Events still lets you treat the devices distinctly if you want to, and no amount of API design can make up for developers who can't justify investing in building a great UX.

[existencebox]

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 chance I'm missing some key point, even reading the spec took some hand waving to put it together in my head) it's largely constrained by the inflexibility of what an event is.

(I'd be very curious for any sort of "why I'm wrong" or "why this isn't feasible/desirable")

[mbrubeck]

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.

[nevir]

Or introduce a whole new hierarchy.