https://bugs.webkit.org/show_bug.cgi?id=105463

Current specification is here: https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html, lots of details still to be worked out about how this would actually manifest in Chrome.

Pointer events offers a number of improvements, and solves important problems with touch events.  However adding a new (largely redundant) input model to the web is not something we can take lightly.  We're actively debating whether the benefits justify the conceptual complexity of having a new input model.  I welcome any comments on this bug (especially from site/library developers using both touch and pointer events today).

+1000.

I consider myself a library developer (I worked on jQuery, created jQuery UI and numerous other smaller libraries). I spent thousands of hours working on dragging functionality across mobile and desktop.

Pointer events give us a single unified event model to connect multiple pointers, regardless of their type, and have them interact with each other. This is *not* simple using the current model, and many things are not even possible. I only see upsides to bringing this to Chrome. Pointer events are not breaking the web in any way, as they are an addition to mouse and touch events, not a replacement. As a library developer, I will only use pointer events going forward in any browser that supports them.

I don't see an equivalent for "click".  This is important, as it's something I have had to implement for touch events in my framework, creating a custom "tap" event to service this need.  Why not use touchstart in that case?  Because then the event will trigger when the user is grabbing that element simply to scroll the page.

I'm working on a large commercial web application that uses many mouse/touch events and I can say that those new pointers would be very handy. True, this is yet another input method, but in my opinion this will be much more practical than having many not connected event models like mouse, touch and stylus (or whatever will come in the future).

I'm a front end developer working on Kendo UI Mobile. 

Touch events are okay if used separately from mouse events - there are a few quirks, but still. However, when Chrome 22 got out, it broke every library out there that was using the touch events as a flag that this was a touch device. This by itself is not a problem, but the current implementation of simultaneous mouse and touch events on Windows tablets (or Android with a mouse) make it impossible to distinguish the synthetic mouse events that are fired after touch end and the real ones, thus making it extremely difficult to support hybrid mouse/touch devices.

With pointer events you have a single unified API which can be either mouse, touch or pen and by handling the several available events one can easily support any kind of input.

Additionally, I'd also like that to say that I had problems with some blackberry devices (such as the bold) that support both conventional mouse events (which are triggered by the physical trackball) as well as touch events (which are triggered by tapping or dragging your finger on the screen).

I added multi-touch support to Cesium, a WebGL virtual globe/map.  I like the idea of pointer events particularly so I don't have to filter out synthetic mouse events.  Currently Cesium disables all mouse input once the first touch event arrives, just to avoid synthetic events, and it's overkill because it breaks compatibility with touch/mouse combo devices.  There are various options such as time-limiting or count-limiting the disabling of mouse events, but if pointer is on the horizon that seems like a better solution.  (I hope I'm not belittling pointer with this comment, it's obviously way more than just a solution for synthetic events).

@anewpage.media There is no equivalent for click, because clicks will happen for any pointer down and up pair. There would be no delay, and no worry that a .preventDefault() would cancel the click.

This looks like a great way to unify events for mouse, touch and stylus. It would not be that difficult to retrofit CSS in my older sites to include touch events along with the current standard mouse event pseudos. 

For the future, it seems like the right way to go. Consolidating user interaction triggers into one standard set for all input methods and devices would make things hugely easier for developers and make for a more unified experience for users.

@dfreedm Thanks.  Delay in the click event (which was the impetus for homebrewing a touch-event equivalent, as others have also done), does not appear the be prescribed in the spec.  Perhaps saying that there should not be any delay at all is the way to go.

The spec specifically avoids talking about the mechanics of click, because click is considered a gesture, and therefore outside the charter of the Pointer Events Working Group.

In an ideal implementation, click would be issued from the primary pointer for each pointerType with exactly the same mechanics as if it came from a real mouse right now.

@dfreedm Indeed, that would be ideal, and I see your reasoning for why that problem is out of scope.

1. In the Pointer Events spec it's unclear to me which element exactly is the target of the events.

Apple's touch events have a very convenient property: touchend and touchmove are always fired on the same element that received touchstart, even when touch ends on top of another element. That makes implementation of dragging very easy, as all handlers can be on the same element.

Mouse events OTOH require registration of mouseup/mousemove handlers on the document in order to receive those events when pointer moves outside bounds of the element where the dragging started. That is more powerful, but most of the time it's unnecessary extra work and/or source of subtle bugs that make dragged elements "sticky".

2. I don't see pointerenter and pointerleave events in the spec. I find mouseenter/mouseleave events much much more useful than mouseover/mouseout as they don't fire bubbling "false positives" when pointer moves over nested elements.

Given that Pointer Events are supposed to map closely to mouse events I'm worried that they copy those annoyances and deficiencies of old mouse events.

3. I don't think Apple's touch events can be dropped without Breaking The Web (regardless of W3C status and patent situation it's a de-facto standard now), and it seems silly to have another API with such massive functionality overlap. 

I'm fine with the fact that "touch" could mean "pointer" in the existing pretty-decent API, especially that Apple's touch event model is soooo much more convenient than the old mouse events and presumably Pointer Events. I'd rather see Apple's touch events API extended than duplicated with Pointer Events.

@pornel The target for PointerEvents is the element under the pointer, at all times (exact like mouse).

As for the enter/leave events, those are in the HEAD revision of the spec: https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html

I actually find what you call the "convenient" property of touch events a major hindrance. If you want to build a web app for both desktop and mobile, you have to use two fundamentally different event systems. It's even incredibly difficult to normalize them into one system because just plopping touch handlers on the document and using elementFromPoint to find the "under the finger" element will disable GPU accelerated scrolling.

Now, PointerEvents does not preclude you from making a system that behaves like touch events. with Pointer Capturing (https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#pointer-capture), you can assign an element to receive all the events for a specific pointer. In this way, you can even get mouse input to behave how you like touch input to behave, which means you can publish on desktop just as easily as mobile! 

I'm a designer who stumbled into creating the jQuery Superfish dropdown menu plugin, so while I'm well out of my depth here, I have had hands-on experience juggling these event systems while attempting to support all browsers/devices.

Microsoft's IE10 lacks the "Apple" touch events, forcing me to add this third interaction event system into my code. While IE10 fires fallback mouse events in an effort to not break existing pages, touch events are not fired (IE10 does not support them, I believe), so they have only half-succeeded at that. This means I am currently required to handle all three systems, whereas if touch fallbacks were fired it would have been a simple matter of letting the pointer events be handled by the existing mouse or touch handlers.

It seems to me that implementations should fire fallback mouse or touch events depending on which the actual user-interaction method matches most closely. I could easily be wrong, but I'm hoping greater minds than mine will consider this and decide accordingly.

As a side note, I wrote a version of my menu system using only pointer events with hand.js as a polyfill for other browsers, and the resulting code was much simpler. So in principle I think pointer events will be great…as long as the transition period is handled carefully.

Finally, I hope pointerenter and pointerleave are included. MS launched IE10 without them, which is worrying to me.

Intent-to-implement thread on blink-dev: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/K1qk6qZWgIc

Split the piece I'm actively working on into issue 241964.

With apologies for cross-posting from Mozilla's equivalent bug https://bugzilla.mozilla.org/show_bug.cgi?id=822898#c24

if in the medium term the idea is for the browser to support both touch events (for compatibility with most touch-specific JS out in the wild today) and pointer events at the same time, how will the simulated mouse events come into play? It seems the two event models are fundamentally incompatible in this respect, with touch events firing all synthetic mouse events after touchend

touchstart > [touchmove]+ > touchend > mouseover > mousemove > mousedown > click

while pointer events dispatch them "inline" with the pointer ones

pointerover > mouseover > pointerdown > mousedown > pointermove > mousemove > pointerup > mouseup > pointerout > mouseout > click

Additionally, synthetic mouse events and click can be prevented in touch events model by doing a preventDefault, while pointer events make use of the touch-action CSS to suppress synthetic mouse events and explicitly do not allow click to be prevented.

I am not the authority, but after following and talking about this technology for a while, it seems like the general idea is to use pointer events when they are available, and mouse/touch events otherwise.

All the pieces are there for you to abstract away into your own all-encompassing solution.  On the downside, said solution can be pretty intense (see: http://blogs.msdn.com/b/ie/archive/2011/10/19/handling-multi-touch-and-mouse-input-in-all-browsers.aspx).

"use pointer events when they are available, and mouse/touch events otherwise" from a JS developer's point of view, of course. but i'm guessing from the browser's point of view, both models will have to be supported, and that's where the synthetic mouse events get in the way as they happen at different times. code written specifically with the order for touch and mouse events in mind can potentially behave erratically once inline mouse events are being fired? it gets even trickier once you factor in how touch and pointer have that 300ms delay (unless suppressed) at different points as well (before all the synthetic mouse events in touch, before the click in pointer)

touchstart > [touchmove]+ > touchend > [300ms delay] > mouseover > mousemove > mousedown > click

vs

pointerover > mouseover > pointerdown > mousedown > pointermove > mousemove > pointerup > mouseup > pointerout > mouseout > [300ms delay] > click

@splintered: those are great questions, and are on my list of the key open issues.  I've just posted my brainstorming doc that covers these issues here:  https://docs.google.com/a/chromium.org/document/d/1Sasl1qYJV6agrDvGplEYlZznzc38U-TFN_3a67-nlSc/edit#

Brief summary:
 - click should be easy - we dispatch it whenever touchstart/touchend aren't cancelled (regardless of whether pointerdown/pointerup are)
 - when to dispatch mousedown/mouseup etc. is much trickier and is probably going to be a compat tradeoff.  I think we just need to try a few options (mentioned briefly in the doc) and see what breaks fewer things in practice.

I welcome comments in that document, but I'm not too worried about coming to  conclusion just yet - my priority is to get touch-action nailed first.

Pointer events support will also result with improved pen responsiveness?
On a Windows 8 Tablet, a Wacom pen has a lag in Chrome which makes writing or drawing on HTML5 canvas almost impossible.
For comparison, on IE 10 the pen doesn't have a lag and writing is fast and responsive.
Chrome on the Galaxy Note has the same issue.

The Wacom support bug is tracked here:
https://code.google.com/p/chromium/issues/detail?id=194865

A report on the lag with a simple drawing app for testing:
https://code.google.com/p/chromium/issues/detail?id=168538&can=4&colspec=ID Pri M Iteration ReleaseBlock Cr Status Owner Summary OS Modified

If voting is still open (unfortunately this ticket still is ;-), I'd like to give my+1 to adopting Pointer Events in Blink.

The "classic" touch spec has been recurringly troublesome for my apps, especially with its "always capture" model vs. removed elements (see <http://lists.w3.org/Archives/Public/public-webevents/2012OctDec/0023.html>). Furthermore, as already noted in several comments, having to handle two different interaction sources (with somewhat different models) is a pain to begin with and becomes even more troublesome when dealing with a user agent which supports BOTH simultaneously.

Pointer Events solves most all of the first generation problems AFAICT. I'm just finally getting "hands on" experience with it via my own Win8 testing device, but it has long looked to be all-around nice model and a well-written spec.

Note for anyone following along at home: the Polymer team has meanwhile provided a polyfill if you want to simply code your app to one model, <https://github.com/Polymer/PointerEvents>

Thanks for your input!  I was just arguing today that pointer events explicit capture was often better than touch events implicit capture for the reason you cite - thanks!

We're continuing to evaluate the tradeoffs of relying on a library like Polymer's PointerEvents vs. native browser support.  Now that we're shipping touch-action in chrome (issue 241964) it should make it easier to have a high-fidelity polyfill.

FWIW, I'd really like to see native support. Let the polyfill crews focus on legacy browsers, please! (Plus, I suspect a lot of web developers would [unfairly] balk at adding a polyfill to make Chrome/Firefox "compatible with IE" ;-)

Thanks.  You definitely won't need a polyfill on Mozilla - it's already got native pointer event support behind a flag: https://bugzilla.mozilla.org/show_bug.cgi?id=960316.

There is absolutely no need to add any new functionality to that browser, let it stay like this for 5 more years, no hurry.

I am not sure why debating adding or not adding a functionality if needed? If a car needs 4 tiers, and it currently have 3, then it needs 4, you can debate as much as you want, how can we reuse the 3 tiers, add a few thousands of line of code to make it look like 4, avoid the highway in the snow, etc. pointless.

Google Chrome is getting close to what IE6 came to many years ago, I still remember reading the interviews and posts with the IE team back in 2001, 2002, IE does everything and there is absolutely no need to add more features, use ActiveX, yeh right, no one is using it today anyway.

Pointer Events is originally proposed by Microsoft. IE11 already supports it.
I tried this API for my Surface Pro game which needs to handle both touch and mouse events and it worked like a charm.

I know there is a risk to have parallel APIs, but I like this API very much.

In our drawing app we need to handle touch and pen(Wacom) separately. For example to disable touch input while drawing with the pen.

I couldn't find a way to handle pen events with the polyfill.

In addition, there is a lag when drawing with a pen in Chrome on Windows 8.1 and Android. That's probably because Chrome treats the pen like touch. With native PointerEvents, the pen will be treated like a pen which will prevent such issues.

I had a HTML-based iOS app with multi-touch support - using only Touch Events - and wanted to make it work on mouse devices as well. All the touch handling code was 47 lines long.
I switched Pointer Events, and that code shrunk to 35 lines - while also adding support for mouse. Huge win.
Of course, the only downside was that I had to add a polyfill (hand.js) to make it work...

After tons of debate and discussion, with lots of great input from our friends on the IE, Firefox and Safari teams, we've decided that incrementally extending our existing input APIs (see issue 404128) is a better path forward for blink (and, we believe, the web) than adopting pointer events.

See a summary of our position here: https://docs.google.com/a/chromium.org/presentation/d/1qRqLKQjOnGgrM-UkMAb2RH6mQCFQHk8R01s5qvjm2Po/edit#slide=id.g355c5631f_134

Very briefly, pointer events has 3 main drawbacks relative to the alternative:

1) Mobile-first web:
Pointer events would likely never supplant touch events on the web (especially without support from Safari).  Since touch events are here to stay, supporting another largely redundant input model has a high long-term complexity cost on the web platform. 

2) Performance:
The hit testing model required by pointer events imposes a non-trivial performance penalty (hit test on every movement event) that neither Android, iOS or touch events has.  We're not willing to add any feature that increases the web's performance disadvantage relative to native mobile platforms.

3) Richness:
Pointer events requires that scrolling and event handling are mutually exclusive.  This precludes some UI effects which are common on on mobile platforms (eg. pull to refresh).  Recently strong developer feedback has lead us to change Chrome in the opposite direction here - enabling event handling while scrolling (see issue 293467).

We're committed to working in the web standards community to improve input on the web, and we especially value the relationship we've recently built up with the IE team here.  Despite this difference in technical opinion on what's best for the web, I'm optimistic that we'll still make good progress together.

public-pointer-events thread: http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0051.html

If pointer-event is being pulled from Blink, we need a solution to replace "pointer-events:none;" which is employed to prevent input triggers on elements.

@raldred -
You are referring to the pointer-events CSS property.
This issue is about the Pointer Events specification, which includes various events for handling mouse/touch/pen/other input using JavaScript.

The pointer-events CSS property is definitely not being removed.

I feel like: "our friends at Apple would never support moving the mobile web forward since we have the App Store" isn't a good answer.

Pull to refresh is such an awful UI.  I was hoping that fad would go away along with the hamburger icon.  Normal users have no idea what either action means.  Scientific testing shows it, but designers just love these two gestures so damn it they'll make everyone love it.

Just want to call out that you can implement pull-to-refresh just fine in IE or a Windows JS app (using native/independent scrollers). It actually works much better than doing it via UI thread touch-event handling. Why wouldn't you be able to do that in Chrome if it had pointer events, if IE can do it just fine?

I get the feeling some of this is more that Chrome isn't set up to handle off-thread input processing and hit testing like IE does via DirectManipulation.

Interesting/related discussion here ""Browsers, Developers and Pointer Events Meeting Notes"" http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0072.html 

@brandon - is the pointer events implementation of pull to refresh available anywhere?

Really couldn't agree more about the performance points being non-issues, there really isn't anything intrinsic to pointer events that would cause a performance _problem_ (sure it may be less performant, but so is writing C, but that doesn't stop me writing JavaScript). IE and Windows 8 applications are already proof of concept to this. It's sad to see this be rejected, I think you should consider updates to touch events as just part of the solution to improving user interaction on the web.

I think the need for pointer events like behaviour will become more and more apparent in the next couple of years as developers really start to realise that touch interaction isn't quite as simple as they first thought.. still today developers haven't grasped that devices aren't merely TOUCH devices like the iPad, but that they can be both touch, mouse and whatever next.

This first became apparent with Windows 8, where you could no longer change your websites UX based on touch being present, or even that a touch type pointer was present.. but you instead needed to react at runtime, and per interaction because a user could be using touch and a mouse/trackpad at the same time.

Chromebooks also followed this pattern of supporting mouse and touch, and so it was really surprising that pointer events weren't seen as a MUST HAVE for Blink, let alone that they wouldn't ever be implemented.

As web developers we'll live- a lot of us lived the IE6/firefox days, and some still do.. the days where you considered your job to be knowledge of quirks and how to tickle browsers just right to accomplishing some kind of faux consistency. It seemed like those days were over, and they mostly are but it seems like this is one battle we'll lose.

@stephen: The idea is that people won't be using hybrid devices in 15 years. Or even mice. They will MOSTLY be using touch devices.  The few user agents which aren't driven by touch will simulate touch events, just like touch devices simulate mouse events today. 

"The idea is that people won't be using hybrid devices in 15 years. Or even mice. They will MOSTLY be using touch devices" I would have actually thought voice, gesture (Kinect-style) etc.

Conceptually, I would have preferred an input-agnostic model. Pointer Events weren't perfect (indeed, even today, they left out keyboard-specific interactions), but they were certainly a step in the right direction in this respect (without getting too far down the other abstraction side like, say, IndieUI). They also enjoyed a lot more cross-browser collaboration on the spec side than, say, Touch Events, which Apple dreamed up on their own and through sheer marketshare pushed to become de-facto standard (while also saber-rattling about patents when an attempt was initially made to retrospectively spec them at the W3C, but that's another story).

As an aside: will we see pull-to-refresh still being a thing in 15 years anyway? Will the boundary/hit recalculations still be computationally expensive in 15 years? If not, these "right here, right now" reasons probably don't matter much in this kind of future-gazing exercise as a rationale for not implementing a relatively new technology.

I agree that in the long run, the only one of my arguments that likely to be really important is #1.  At the moment it appears to us that touch events has a better chance at having a widely supported input model for the web of the future than pointer events does.  Having a single interoperable input model supported by all major browsers is our #1 priority here.

@jakearch - See http://dwcares.com/pull-to-refresh-2/ for the implementation by @dwcares. 

It's more built on CSS manipulation features (scroll chaining and snap points) than Pointer Events. But that's the better way to do that UI anyway. Then you have a multi-threaded interaction which is going to be way more smooth and responsive matching native app independent manipulation behavior (at least on Windows). I believe Mozilla and Apple support those CSS additions, hopefully Google does too. Also, zoomTo can't come fast enough, and that one helps in this interaction.
 

@anewpage - Whose idea is that? I've never heard anyone make that claim with anything to back it up. Clearly we aren't on a path to that now. Maybe someday we'll live in Star Trek with voice and touch for everything, but it's a real stretch to bet any design decisions of today on that vaguely possible outcome.

Touch is an incredibly useful input mechanism for all sorts of cases. But it's in addition to mouse/trackpad/etc (and pen), not a replacement. Mouse didn't replace keyboard (not even the arrow keys!), and touch isn't going to replace mouse.

Oh, and off-topic, but the captcha I'm seeing right now below this box must be someone's idea of a joke.

> At the moment it appears to us that touch events has a better chance at having a widely supported input model for the web of the future than pointer events does.  Having a single interoperable input model supported by all major browsers is our #1 priority here.

Putting aside the fact that Touch API is *not* interoperable already (and will be even less so after the extensions), reflect on the parallels here to the early 00s when Microsoft had their proprietary event model while the W3C was standardising DOM events. Imagine what the Web would be like today if Mozilla decided that because Microsoft wasn’t responsive to the standards process (like today with Apple and PE) that they wouldn’t implement the technically superior W3C event model and would instead embrace and extend the Microsoft model.

Do you really think the Web platform would be in a better position today if that had happened? Because that’s exactly what you’re saying is going to happen here.

Absolutely not - we are committed to the standards and consensus process and will definitely NOT be adding new APIs which are not standardized. See http://www.chromium.org/blink#new-features.

@csnover -
One big difference here is that while iOS has a lot of market share that is not going away (like Microsoft), iOS does not allow other rendering engines (unlike Microsoft).
If iOS does not support it, the chances of success in this battle are unknown but, apparently, pretty slim.

With that said, adding this API using some kind of an opt in method (like document.msCSSOMElementFloatMetrics) might not harm performance and might not be such a terrible idea.

@rbyers -
I am not sure csnover referred to you, csnover compared Apple with Touch Events to Microsoft with attachEvent.

Apple may have a large percentage of mobile usage share now, but this is changing steadily. As Android grows (and Windows Phone in Europe), developers will increasingly write for the standards-based API and Apple will be forced to implement it.

> developers will increasingly write for the standards-based API and Apple will be forced to implement it.

Just to be perfectly clear: Touch Events have become an actual standard, though that's not how it started and Apple did not participate in the standards process. The Blink team also does not plan on building anything that does not have an official standard, though they plan to write new (or extend existing) standards to get the features they want, so long as there are other browser vendors that are willing to implement.

With that being said, it is my hope that developers will increasingly write for Pointer Events rather than Touch Events and use polyfills where necessary. If this becomes common, the Blink team will need to respond to developers saying, "Look, IE/Firefox is faster because it doesn't require the polyfill." That will be a major factor in reversing this decision. Unfortunately, we don't know how effective that will be for Apple, but we can hope that if we reach the point where Safari is the only major browser not supporting Pointer Events that they will be driven to add support.

@phistuck -
> One big difference here is that while iOS has a lot of market share that is not going away (like Microsoft), iOS do not allow other rendering engines (unlike Microsoft).

That’s true, but if we’re going to use “iOS will support it” as a test of whether or not to implement things, we might as well give up and throw away the Web platform today, since it means we’ve made Apple the single de facto gatekeeper over all possible features that might touch the mobile Web (which, in the opinion of the Blink team, is to become 95% of the Web).

@rbyers -
> Absolutely not - we are committed to the standards and consensus process and will definitely NOT be adding new APIs which are not standardized.

As Scott mentioned while I was in the middle of writing this reply :), Apple did *not* standardise Touch Events before they implemented it (actually they played games with their patents to make it more difficult). People from W3C, Opera, Mozilla, and Nokia wrote TE into a W3C spec. The same thing could have been done with the IE event API, at which point we would be in the *exact same place*.

    "The idea is that people won't be using hybrid devices in 15 years. Or even mice. They will MOSTLY be using touch devices.  The few user agents which aren't driven by touch will simulate touch events, just like touch devices simulate mouse events today."

In no way you can predict which input will be used in 15 years. Not even in 5. It will definitely be a kind of hybrid and may be part touch, but part speech or think or whatever. I think this is no argument at all and I think we as developers want a sensible think today and not for a future might-be.

Just today we worked on an iOS webapp (which should ALSO run on desktop) and run immediately into problems with touch events and other events. Even helper libs like iScroll seem not to help, actually make it worse. 
I do think the IE addEvent <> W3c addEventListener is quite a valid analogy. Whereas that was actually simple to wrap where events are not :(

The argument made above that when every browser would support Pointer events iOS would be forced to support it too. Maybe in even less time IE took to support addEventListener ;)

@phistuck "if iOS does not support it, the chances of success in this battle are unknown but, apparently, pretty slim"

Then, one wonders why anyone bothered implementing WebGL, Strict Transport Security, spdy, navigation timing, pointer lock, resource timing, web speech, shadow dom, etc etc. 

That's quite a specious argument; the general feeling was Apple wouldn't release WebGL into the wild for various reasons; IE said outright they would never support it, now its here in all browsers and the web is a much richer place for it.

"The idea is that people won't be using hybrid devices in 15 years. Or even mice. They will MOSTLY be using touch devices."

Touch is great for consumption but not so good for creation where a greater fidelity is needed. People use apps on iOS but they don't generally make them on iOS with touch as that would be a pain.

The creation industries where touch is preferable artists, graphic designers need higher precision (for tablet/stylus support https://code.google.com/p/chromium/issues/detail?id=194865) which is where extending the touch api to include pointer type and pressure are coming from https://code.google.com/p/chromium/issues/detail?id=393462 how with that work without iOS support?

What people will be using in 15 years is more probably why the touch api shouldn't be extended but be generalised and pointer works better here, I'm not saying its completely right for this imagined time.

Pen angle and pressure aside, even now things other things are emerging:

How is touch going to be extended to work with my 3d touch and hand angle with a Leap Montion controller? Whether is a finger, a fist, a palm a pencil?
How is touch going to be extended to work with my head orientation and eye focus with an Occulus Rift?
Even how is touch going to be extended to work with my eye gestures in a future Google Glass?

csnover@
> Apple did *not* standardise Touch Events before they implemented it (actually 
> they played games with their patents to make it more difficult). People from
>  W3C, Opera, Mozilla, and Nokia wrote TE into a W3C spec.

Ah, sorry - I thought you were referring to Google here, not Apple.  I agree this whole mess would be a lot simpler if Apple would participate in the input standards process.  And by the way Google (eventually) was part of getting TouchEvents standardized, I'm part of the working group (and was one of the folks arguing it should be shut down in favor of pointer events, back 2 years ago when our view of the future was different).

@rbyers-

Could you please answer the question I raised in comment #81, about if you think it would have been good for the Web in the '00s for non-Microsoft vendors to copy the IE events API into a standard and then not implement the DOM 2 Events API? Specifically, it would be helpful if you could share why you think this situation is somehow materially different. Thanks!

@rescendent -
On second thought, my phrasing was a bit extreme. "slim", specifically.
Anyway, I only meant on mobile and tablets. The features you mentioned are very well suited for (touch or non touch based) desktops (as well as on mobile), so I would not consider those as great examples for your argument (desktop Safari does not have enough market share to assume any kind of dominance at the moment).

Firefox has not announced official support for this feature yet (I mean, an official release that supports Pointer Events). If they release Firefox with Pointer Events support, I guess this may change the state of the world. If more and more websites use it, that could also change the state of the world. So I guess nothing is ever final.

Firefox is working on, and plans to ship, Pointer Events on all devices. See http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0072.html

Someday Apple 'll make Mac with touch input they 'll be in collapse because most sites which uses TouchEvents assumes there are not other inputs like Mouse. And if in this situation there in the world 'll not be PointerEvents, Apple 'll develop their own realization of Pointer/Touch/Mixed Events. Just immagine this situation. Even more fragmentation.

In some day, IE was 50+% of all Web and IE had support only for attachEvent, but other vendors pushed addEventListener model forward and it's won. If we did not stop Safari now, Apple 'll introduce more proprietar API. Let's break it earlier.

@scott.gonzalez -
Thank you for the link! Interesting (and very annoying of Apple not to join these discussions).
Note that nothing explicitly says Firefox plans to ship. They are currently implementing it, yes, but nothing there says "plans to ship" and the like. Nothing is certain yet.

Just checking I have the summary correct, either the touch api needs extending or something like pointer events needs to come in. There is web developer support of pointer events (as evidenced in this thread).

Question, can touch events be extended in Chrome on iOS without Apple's support? Have Apple given their support? If not then the iOS angle is irrelevant to this discussion?

In which case the players are the platform holders Android, FirefoxOS, WinPhone, Windows, ChromeOS, Linux, MacOS and the browsers on these platforms Chrome, Firefox, IE (I assume Opera is in the Blink camp)

Win/Droid/MacOS/Linux are mixed mode as they work with multiple browsers; so its the browsers that determine the platform. 

*Pointer events (W3C Candidate Recommendation)*
Browsers: IE supports, Firefox implementing+maybe, Chrome looking for a solution.
Walled gardens: WinPhone supports, WinRT supports, FirefoxOS implementing+maybe, ChromeOS looking for a solution

*Touch extensions (Unspecified)*
Browsers: Chrome looking for a solution, IE unknown, Firefox unknown
Walled gardens: ChromeOS looking for a solution, WinPhone unknown, WinRT unknown, FirefoxOS unknown

Is that correct?

I've already had to rewrite a book chapter on input on the web because of Chrome dropping support for Pointer Events (you were the good guys- along with IE you form an 800lb gorilla) to be a lot more bleak (now Chrome is the bad guys and we don't have any solution on the horizon.) Nothing would please me more than to revert to the original take on that chapter. 

I also don't want to pin my hopes on this issue getting sorted out on the vague promise of "extensions" to the existing screwed up mess. What guarantee do we have that Apple will be any more interested in "extensions." Will Chrome's BFFs on the IE team be interested in "extensions?" If we're looking at incremental extensions as the solution (with no more details than that,) I will be retired, drinking coffee at Sant'Eustachio Il Caffè and struggling my way through La Gazzetta dello Sport before the issue of user input on the modern web is sorted out in a way that benefits developers and end users. Smart people are doing stupid things with this stuff because it's a complicated issue. Browser vendors and the W3C have to lead on this and sort it out from up on high because the bottom up approach isn't working right now. 

Apple's objection in 2012 https://lists.webkit.org/pipermail/webkit-dev/2012-December/023050.html as referenced by http://www.chromestatus.com/feature/4504699138998272

You know what this whole mess reminds me of?
The back-and-forth on <picture> and srcset.

Developers pushed back hard against the 'hard' technical aspects that some of the browser vendors were using, and here we still are: leading up to a solid adoption of the superior picture API after all. Maybe Google ought to think this one through a bit more. Surely, recent history is not in their favor.

Having said that; I'll continue to use pointer event polyfills. Fast experience where the real thing is supported, worse experience where not. If that means IE and Firefox end up getting a better experience than Chrome, then that's Chrome's problem. The value gained vs. time spent futzing about mixing mouse and touch by hand makes it simply not worth it to most projects out there.

I don't have the time right now to reply to every comment on this bug, but I am reading them.

One thing I want to clarify: we're not "dropping support for pointer events" - we've never agreed (or started work) to add them in the first place beyond touch-action.  Eg. see my comment #11 on this bug from February 2013 saying we're trying to figure out whether the benefits outweigh the costs, and this intent-to-implement thread from May 2013: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/K1qk6qZWgIc where we said we weren't comfortable implementing Pointer Events natively in blink.

@csnover:
> Could you please answer the question I raised in comment #81, about if you think it
> would have been good for the Web in the '00s for non-Microsoft vendors to copy the IE
> events API into a standard and then not implement the DOM 2 Events API? Specifically,
> it would be helpful if you could share why you think this situation is somehow
> materially different. Thanks!

Clearly that would have been bad - addEventListener is a better API.  The material difference is that BOTH 'addEventListener' and 'attachEvent' were incremental extensions to the model used by millions of existing applications (opting in to using them was a "pay for play" choice that didn't require you to rewrite other code - see http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0090.html).  So the closer analogy would be if the addEventListener model had required, for example, changes to the Event interface used by most consumers of events.  If that had been the case, then yes I would have advocated that standardizing the attachEvent model and implementing it widely was the more pragmatic choice.

> The material difference is that BOTH 'addEventListener' and 'attachEvent' were incremental extensions to the model used by millions of existing applications

There are *significant* differences between the old-IE and W3C event models. Only in the most simple cases could you consider either to be an incremental extension of the other, or to the previous DOM0 event handlers. jQuery has a thick wrapper around the mess for that very reason, yet still there are plenty of edge cases where it does not behave consistently across the two.

> opting in to using them was a "pay for play" choice that didn't require you to rewrite other code

Whoa, I disagree. With attachEvent/addEventListener you either ignored one, writing code that broke on one or the other browser, or you wrote essentially two code paths for your event handling, or you used a library like jQuery. That's not "pay for play". A decade ago the web was littered with code that demanded IE behavior, because IE was 90 percent of the browser market. Let's not forget what Opera did to achieve IE compat.

Re the post on lists.w3.org, the only time you'd need to rewrite is if you found the touch event model to be lacking to the point where a pointer event rewrite was needed to add some new feature or functionality across the platforms you cared about. That seems reasonable, it's exactly the situation people find themselves in when their library or framework makes a major non-backcompat jump. They can either stay with the limits of the old or take the time to upgrade. Having the browser maker push the work off to the framework/lib authors doesn't make it go away, although it often does make it go slower.

Actually, addEventListener did require a completely different event interface.  attachEvent() used the global window.event which merged all the properties from all the event types into one interface. Developers convinced us that addEventListener and the associated Event interface and propagation model (which was also different) was a better API, so we implemented that. ;-)

Sorry, attachEvent was before my time working on the web platform - clearly my reading on this gave me an overly simplistic view.  I'd like to amend my answer to "I can't comment on how it relates to the attachEvent/addEventListener history because I don't know enough about it".

Just in case the silent-but-happy crowd is not being fully "heard", I'd like to echo that I agree completely with the Chromium team's direction and reasoning. With Windows Phone 8.1 Update 1 adopting the touch event model alongside this announcement, it seems like the right move to me.

I think it's silly logic though. You're going to get as much fragmentation trying to expand on a standard that Apple didn't even write, much less express interest to participate in. A clean break with an elegant API that's already going to have the backing over the two other Web Giants (MS/Firefox) seems a lot more sensible than trying to...force touch events into something it's not. There's clearly a call for a nicer API and Chrome is doing the web community a disservice by avoiding this Spec. This isn't Microsoft trying to force a proprietary vision onto the web, this is MS trying to make the web a better, more consistent, and largely future-proof place for developers. Added my star and very interested to see how this conversation proceeds.

Don't drag behind the web by insisting on TE. PE is the way forward.

I don't see why not implement this, especially behind a flag. Fine, you think PE API isn't ideal and there are subtle differences between it and your vision, but it seems to me that you're looking at the advanced use cases when you argue against PE. Either way, it's behind a flag so it's not an "official" way to use events, whichever model you end up supporting.

Most web apps will be simple and I haven't yet met a developer (especially an 'average' one) who preferes 3 APIs vs 1 API for something, particularly when that something is considered a fundamental thing like input handling. For advanced cases, people are free to use your 'better' API, for us others that just want to cover as many browsers with as little code as possible and go home to our families at the end of the day (and not spend nights implementing N APIs for M browsers), please let us have one unified API even if behind a flag.

Thanks for listening.

to #108

"behind a flag" is not a key here. It's just first iteration of intergation. Any API which is permanently behind a flag is useless.

I think the decision to not implement Pointer Events is very sad. While I agree with the nit-picks on Pointer Events, Touch Events is a far worse API. Couldn't the Pointer Events be adapted to work good in all use cases instead?

As I have understood, the targeting on which Element to fire the event on is expensive with Shadow Dom. If this is correct, wouldn't Mouse Events have the same issue? If so, wouldn't an opt in/opt out of targeting work (preferably settable per event handler).

To fix scrolling (pull to refresh and similar), can't PE be extended to handle this in a good way? (the current TE way is pretty bad so a hit on this would be preffered anyway).

As of right now, a wrapper framework or polyfill is required *on all platforms* if you want to handle input on all devices - talk about a performance hit! Whereas if Blink were to implement PE, then a polyfill would *only* be needed on iOS devices. That seems like a much better (and performant, and web-developer-friendly) outcome, no?

So, let me understand this madness: are we doomed to write our web code 3 times for 3 different APIs because you cannot find a way to provide an unified solution? You must be joking, right? I hope so. Because from outside, this mess appears as nothing less than total incompetence. This is the most damaging "WontFix" ever.

I agree with the others who claim that only implementing Touch Events will mean having to use a wrapper framework/polyfill to accommodate different types of interactions.

90% of the time Chrome's choices bring the web forward, but the decision not to pursue Pointer Events will be seen as a poor one as users inevitably rely on increasingly diverse input devices and technologies that bring web development to desktop applications, like Atom-Shell and Node-WebKit, become more popular.

No matter what Chrome decided, it was clear you were always going to have to support touch events (unless you can ignore Safari).

> No matter what Chrome decided, it was clear you were always going to have to support touch events (unless you can ignore Safari).

I’m not sure what this comment is in reference to but we’ve been over this before. See comment #89.

> No matter what Chrome decided, it was clear you were always going to have to support touch events (unless you can ignore Safari).

You can ignore Safari when you're using WebKit for desktop applications, as with Atom Shell and Node-WebKit. Don't forget that WebKit isn't just a browser anymore.

Point Events are more important to me than Web Components. Anything that provides a more robust browser API should be welcome. I have difficulty understanding why this can't exist?

I totally agree that PointerEvents are more important that the shadow DOM based web components, what is the point of them unless they can be properly interacted with! Usually I look to Blink and V8 as the leaders and pretty well all I need in a webview for hybrid app development and I will continue to expect only the best. Glad to hear that PointerEvents have now reached the W3C Recommended Status. Hopefully we can continue to move forward.

Touch events R inadequate, and since Google has no real plans of replacing it, it seems best to stay with using PointerEvents from hand.js, jQuery, or others. If anyone can list others, please feel free to recommend those too.  

#120 http://hammerjs.github.io/ is another good one

#120 I was using hand.js (https://handjs.codeplex.com/) but the jquery team is backing PEP, so I may switch when it matures: https://github.com/jquery/PEP

I'll be using a polyfill for as long as it takes the Chrome team to change their mind on this issue. Unwise decision, IMO.

I know for my applications, I will be refusing to support Chrome considering Blink developers want to bow down to Apple. And that's only because it seems their decision is to not implement a spec that everyone else is supporting besides Apple. Tsk, tsk, Google. You've been slowly turning into the New World Microsoft. I applaud you in evolving to this state. I think there should be more developers boycotting browser vendors who try to work against the standard.

The bug tracker is not a good place to debate closed bugs, especially when discussion devolves.  (It's not really a good place to debate any bugs; it's a work tracker, not a discussion forum.)

rbyers is welcome to post a pointer to an alternate place for considered debate if further such debate would be useful.  Closing to external comments.

Hey Peter,

This issue is still being actively discussed and we're seriously interested in developer feedback here.

Rick Beyers (the owner) is the right person to decide about opening/closing it. He's OOO ATM but I think it's appropriate to let him make the call when he gets back.

> we're seriously interested in developer feedback here

At this point, I think implementing touch events in Chrome for desktop might break the Web. Example: CSS hover is sometimes disabled/enabled based on touch event support.  UI like hover-activated subnavs would fail in this case.

I'd like to know what exactly is the strategy and roadmap for unified input (be it touch or otherwise) on Chrome Desktop and Mobile?

If you're looking for developer feedback, I'll bite with my current thinking:

1. I don't blame the Blink team too much for backtracking here. I can imagine that maintaining two multitouch eventing engines, that need to co-exist seamlessly for probably a decade or more, is not something one would sign on for lightly.

2. It's still a shame. Microsoft donated a solid spec grown out of many many years of experience with just about every form factor (POS systems, PocketPC, TabletPC, Surface, Windows Phone, etc.) but now Chrome is still stuck with the way Apple happened to "burn their boats upon arrival in the new world".

I'm _not_ saying that Apple's spec is all that bad. It does have its shortcomings in some situations (consider what happens to a touch when its original target is removed/replaced in the DOM!) but generally those correspond to conveniences under other use cases. And of course they correspond nicely to the NSTouch/UITouch eventing on their native platforms.

But what I do believe is that Pointer Events are a superior solution *for the web*. I don't like to think of HTML/JS/CSS as a "cross-platform toolkit" but as its own platform it does need to be inherently portable. Pointer Events are wonderfully abstract, while at the same time mostly compatible with ye ubiquitous olde mouse events that everyone knows and loves [to hate ;-].

To borrow the meme, Pointer Events are the "responsive design" of UI interactions — no more touch codepath vs. mouse codepath. They would lead developers to write code that's not just compatible with a desktop, or a phone, but also just as naturally with, say, touchscreen laptops and a pen-enabled tablets.

When Chrome gave up here, the spec lost an important ally and you could feel the excitement shatter (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=822898#c84). I hope at least Microsoft stands their ground here, but the way things are left here, wishing for that is moving forward with an eternal polyfill…or rather: "polyfills", because there's _still_ no clear winner.

So I wish that Chrome and Firefox would both just make Pointer Events happen, leaving "the other(s)" to catch up or — as is more often the case these days — fall behind.

Very good points by last commenter (#128). I don't think TE and PE would have to coexist for that long (a decade?) though. Say Chrome implemented it in a year on at least touch devices and Apple was forced/likes ;) to implement it too then for iOS lets say in 2 or 3 years (iOS11?) in 4 or 5 years you won't have to support touch events anymore as iOS adoptions was quick in the past at least and Android support would be more or less complete by then, even older Androids would be mostly gone in 5 years. A lot of ifs but reasonable ifs.

It is disappointing to ignore the hard work of the standardization Group

The feedback is very simple: Implement PE and phase out TE as soon as possible. If 3 major browsers lead the way, Apple will have to suck up its ego and follow.

Lead the way forward, don't defer to Apple.

Please implement PE. It is a W3C standard after all.

I agree please implement the standards.

Your slogan...
Remember it??

Move the web forward. 

Then by all means get the W3C Pointer Events implemented!
There is no downside to it, except maybe a better more open web.

I begin to Wonder if it is politics hindering the implementation?

Implementing Touch Events on Desktop has broken several libraries that try to use feature detection to decide on whether to bind to touch or mouse. I've just gone through some code and set flags to negate mouse actions when initiated by touch to enable a library to work on multi-input devices like the Surface Pro. With Pointer Events, I have only two binds, now in Chrome I have 4 binds and two flags to negate mouse actions just to sufficiently handle an enter/leave scenario. If you're going to ignore standards then maybe make it easy on us and support some HTML conditional comments like <!-- IF CHROME -->, jk.. please just implement the standard

The web needs a unified event system. As a web developer working on various platforms, we must write code that handles it all. Its incredibly frustrating and PE sounds like a great step in the right direction. 

pkasting: In this case I'd like to leave the bug open for comments. We're still watching this space and for lack of a better forum I've encouraged people to contribute new data in the debate here (perhaps a centi-thread at input-dev@chromium.org could be a better forum, but not much).  Our concerns with PE are mainly about the difficulty of attaining wide developer adoption, so open discussion with web developers is essential to good decision making. I agree that most comments add nothing new to the discussion, but I'm reading them all and there are occasionally good points.

slightlyoff: thanks for quickly re-opening while I was on vacation.

I'm absolutely for PE it gives me that single set of events to manipulate user input, at the moment were all having to use polyfils or write custom normalisation code, that's not the future. I agree with everyone above. Chrome please lead from the front like you have been, join MS and Mozilla on this.

Rick - thank you for re-opening.  I am going to echo #128 here (as well as other excellent comments above) and add my voice to the list of those who would like to see a unified option that works for the web.

Ideally, the presentation issues are solved by the new CSS interaction-features module of the media queries specification, and any discovered behavioral issues are worked out for the next iteration of the PE spec.

Touch events are decent, but bifurcated code paths are not.  Ideally, the PE spec could be improved to provide for those few cases where it doesn't work elegantly (i. e. pull-to-refresh) - but even if it was frozen where it is today, it would still (to my mind) be a better model than the touch / mouse bifurcation we are currently dealing with.

I'm using pointer events with a polyfill at the moment, and I'm certainly not going to change that. If chromium is going to implement this, I guess Apple has to do so too, sooner or later. So please implement this.

One great thing that pointer events could give us is the ability to dynamically switch the interface depending on the user's current input type. It's almost impossible right now (at least without a pile of dirty hacks), considering the presence of touch events doesn't guarantee that the user is using touch.

Plz implements this. Pointer events is really important.

As a web developer given a choice of APIs, I would tend to go with the one that is conceptually more elegant and polyfill the browsers that don't provide support. Of course standards come into play here as well. For both of these reasons, I think that pointer events will win in the end - provided that it remains an elegant solution. If not, then make it more elegant! Touch events and associated Tomfoolery to get around different input methods will become a monster.

If Apple don't support the standard set by the other browsers then the UI experience will degrade on their browser platform - it's as simple as that! In the web developer world, nobody likes Safari anyway - probably because it falls short as a desktop browser and it has begun to lag behind now in other areas too like IE once used to. We all want websites to be as cross-device and as cross-platform compatible as possible with the minimum of effort - but this needs to include input methods! Of course since we must all develop for mobile nowadays we are forced to care about Safari, but what it comes down to is iOS vs mouse/pen/etc... Polyfilling is both the simple and logical answer in this situation. And that's assuming Apple continue to neglect emerging web standards. (Which can only be to their own detriment in the end)

I also think it is a shame that Microsoft haven't stuck more to their guns on pointer events. But the problem is losers can't be choosers and they entered the mobile game late so now they are playing catch-up. And of course they are by now well and truly used to having their plans thwarted by other browsers. But input methods are an issue that shouldn't just be shrugged off. We are talking about something that is fundamental to how web applications interact with a human-being! Just think how many annoyances will be avoided in the future by having a well thought out, robust and future proof API that makes it easy to support different input methods from the very beginning. Discarding it really is a step backwards!

If uptake by developers is an issue, then all we need is some marketing in the way of easy to understand online code examples. A busy developer will cut and paste without even caring if there's an alternative API, I promise! Of course they may just cut and paste their own code which uses touch events, but there are still many developers who are only just migrating their code from the desktop to the mobile platforms. If you can show how easy it is to take existing code designed for a desktop mouse, make it work well on a mobile device, and then extend it, they will pick pointer events. Polyfilling Safari for iOS won't be an issue because it won't break backwards compatibility. On the other hand, if it seems too complicated and risky to simply change existing desktop code, they will bifurcate, forgetting about other input methods, and they may pick touch events instead...

Sorry, I clearly didn't think that last paragraph through properly there as it's late at night. They will be forced to bifurcate of course. (At least for the next few years) But anyway, the rest of my comment still stands. You just need to convince busy developers to go for it somehow.

Thanks for all the feedback everyone.  We've heard it loud and clear and are working on a plan to hopefully allow us to ship pointer events in Chrome. See https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ODWmcKNQl0I

Kudos for listening and thinking about reversing your decision.

Filing a new bug to track implementation (issue 471824) since the 148 comments on this bug make it hard to follow.

Feel free to star issue 471824 for updates, but please don't post comments unrelated to the implementation work there.  Questions/feedback can be directed to input-dev@chromium.org.