The unifying nature of pointer events is what makes them so important for the future. Otherwise you have to implement multiple pointer models on a device that provides more than one, or try to simulate one from the other which becomes a mess of lies that the app developer has to sort through.

I've already worked with a couple of companies that have been bitten by assuming a device has either touch or mouse, but not both. They had code to the effect of `if ( touchstart in document ) { attach touch events } else { attach mouse events }` but then they ran into Chrome on a Windows 8 system with a touch screen. Whoops. Now their site only works if you touch the screen.

If you think this is "only a problem on those crazy Windows 8 notebooks" then you're not thinking ahead to systems that will use a Kinect, eye tracking, or some other advanced technique to implement pointers. Devs are really going to hate it when those interesting input methods are sliced and diced into mouse or touch (or God forbid BOTH) in order to shove it into Apple's 2007 vision of a web page input world.

There is already the need to support alternate input mechanisms in the form of accessibility and keyboard navigation.

Creating UI widgets that work well everywhere is a non-trivial task that is frequently underestimated.

What this really highlights is the need for high quality UI toolkits which abstracts these details. If a developer is complaining about supporting mouse and touch, then they're most likely missing out on many more details and should be using some pre-built components instead.

> If you think this is "only a problem on those crazy Windows 8 notebooks"...

Many Chromebooks also have touchscreens.

> I'm pretty sure Microsoft is going to go full steam ahead with pointer events.

Note that even Microsoft acknowledges the "touch events are here to stay" argument: IE mobile now supports touch events: http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web...

Yep! We're committed to interoperability and compatibility for sure, and that includes implementing Touch Events. But, we don't see that as a blocker for moving the web forward with better models. Table layout was terrible.

For example, we've built better layout APIs (grid, flexbox, etc). Table layout still exists and is probably "here to stay". But we've nearly eradicated it from the modern web and moved the web into the future of responsive design. We can do this with input too.

Correct me if I'm wrong, but wouldn't Google themselves be one of those vendors as well? Android has cursor support, and there are a few ChromeOS laptops that ship with touchscreens as well. Although, not owning any of them, I'll readily admit that I'm not sure if/how the browser distinguishes between those events - the OS might be abstracting all of that away too.

Right, we (Chrome team) definitely care about multi-input-device scenarios (I started at Google by leading the chrome work for the chromebook pixel). We're just trying to project out 5-10 years where we expect most Interent traffic to come from phones/tablets to a mobile-first (touch-first) world - rather than carry the baggage of the mouse-centric world. Here's some ramblings on how we may be able to evolve touch events to fill this need: http://crbug.com/404128

Sure, I don't doubt there are other vendors too, and it'll be useful for everybody. Just seems even more so for Microsoft, given their push towards that sort of thing.