Intent to Implement: Pointer Events in Chrome | Hacker News Reader

Intent to Implement: Pointer Events in Chrome

groups.google.com

137 pointsshawndumas43 comments

Apple's continuing opposition is disappointing.

The situation with Safari is a worrying echo of Internet Explorer's heyday, with an important player dragging their heels when it comes to implementing standards.

I'll be curious as to how this plays out. Safari, even on mobile, isn't anywhere near as close to the sort of dominance IE had at its peak, so I'd hope pressure over standards will eventually force Apple to capitulate.

Developing on mobile Safari/ui+wkwebview feels very much like developing on the IE of olde. It's hard not to perceive malice in the form of wanton disregard towards open web technology when observing how many stupefying bugs exist in parallel to the immense profitability of the app store.

No, it really doesn't, and you're blowing it out of proportion.

What "stupefying bugs" exist in Safari that aren't much more simply explained by Apple being something of a laggard when it comes to implementing web standards?

pointer event madness. file selector crash. <option> crash. rem bugs. insane RAM usage. crash from RAM usage. crash from greedy CSS selectors. canplay event never fired on media.

That's just from the last few weeks. Can't imagine anyone who has built a moderately sized web app would think Safari's biggest problem is just being a little slow on the uptake.

In better news, wkwebview is a big improvement. Hopefully it's a sign of things to come.

Do you have bug reports for any of those? That RAM usage in particular suggests that the problems are more likely either specific to your application or an extension

Here are some I'm aware of:

https://github.com/jquery/sizzle/issues/290

https://github.com/jashkenas/underscore/issues/2081

https://github.com/jquery/jquery/issues/2145

Webkit devs are aware of these and they have been fixed in Webkit core, but Apple doesn't provide any info about when the fixes may see the light of day.

that aren't much more simply explained by Apple being something of a laggard when it comes to implementing web standards?

Which is my complaint. We only just got WebGL, still no UserMedia, Fullscreen APIs. It's disappointing to say the least.

http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-B...

iOS Webkit still has the 300ms click event delay even though Android released a simple fix over a year ago.

To work around this, you'll have to use a library like FastClick (which is not perfect) or write some Javascript to hijack touch events.

I've also run into a number of CSS animation issues which are just bizzare. For example, "position: fixed" doesn't apply when a CSS transform is also applied to an element.

I was skeptical so I looked it up:

> Chrome 32+ on Android with width=device-width in the viewport meta tag doesn't have a 300ms delay, therefore listeners aren't attached.

[1]: https://github.com/ftlabs/fastclick#when-it-isnt-needed Android Firefox ref: https://bugzilla.mozilla.org/show_bug.cgi?id=941995

What is their reasoning for refusing to implement them in WebKit?

Maciej thinks touch and mouse are different enough that a common API across the two doesn't make sense, and that devices primarily support one or the other (e.g. he believes the touchscreen on a Pixel and the trackpad on a Surface are just rarely-used gimmicks). He also throws a punch to the effect of "if MS doesn't value compatibility enough to use what we already shipped, why should we try to be compatible with them?"

https://lists.webkit.org/pipermail/webkit-dev/2012-December/...

Of course Microsoft has now shown the DO value compatibility enough to implement Touch Events, and is even one of the most active members in the Touch Events community group working to improve Touch Events in the W3C.

Also worth noting, for those who don't already know, that Apple has not participated in any of the W3C efforts to standardize Pointer Events or Touch Events.

In fact, Apple worked to hinder the standardization and implementation of Touch Events, by applying for patents on the API and refusing to license them under the W3C patent policy. So it's a bit rich for Apple to criticize other browsers for not implementing an API that Apple was trying to keep proprietary. (Or to chastise other vendors about compatibility when they won't even participate in the relevant standards groups.)

Please show documentation where Apple refused to license under W3C patent policy. From everything that I have seen, things went more like this: Apple was doing due diligence and reported their patents to the W3C. The W3C then abandoned the recommendation process at that time without pursuing patent licensing discussions of any kind with Apple.

> Please show documentation where Apple refused to license under W3C patent policy.

Sure. From the TE-PAG report, Apple expressly excluded its Touch Events patent claims from the W3C patent policy:

    Patent Advisory Groups are formed when patent claims are asserted
    against or expressly excluded from royalty-free implementations of W3C
    Recommendations.  That happened here when Apple excluded certain of its
    patents and patent applications for the Touch Events Specification.

Source: http://www.w3.org/2012/te-pag/pagreport.html

> W3C then abandoned the recommendation process at that time without pursuing patent licensing discussions of any kind with Apple.

Not true. After five months of work, the PAG officially recommended in July 2012 that the Working Group continue developing the Touch Events spec, which it did for over a year before publishing Touch Events as a W3C Recommendation in October 2013: http://w3.org/TR/touch-events/

The PAG repeatedly invited Apple to meetings and requested other information from them; Apple never replied to any of our communications. This is recorded in the document above, as well as the PAG meeting minutes.

Disclosure: I am co-editor of the W3C Touch Events spec, and a member of the Touch Events Patent Advisory Group.

Thank you, I've never actually seen that information compiled in one place.

As far as I can see, touch events are not yet supported in IE: http://caniuse.com/#feat=touch

And also note that the posting on the webkit list is from 2012.

IE11 for Windows Phone supports Touch Events; IE11 for Windows desktop does not. (It's true that at the time of that email, neither did.)

http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web...

The latest IE "tech preview" release supports Touch Events on all platforms, and so do Project Spartan preview builds.

It sounds like Microsoft just added support with an update to only mobile IE11 less than a year ago, which was a year and a half after Maciej's comment quoted by bsimpson that rbyers is responding to.

Yes, that is true.

As someone who's been using Wacom tablets since before the iPad existed, one of the nice things about Pointer Events is that they provide native support for every pointer-based input device. The only way to utilize a tablet on the web before was either

a) through mouse emulation, or

b) with a barely maintained proprietary plugin from Wacom that only worked in JS, at a time when most rich apps were in Flash.

Pressure and tilt on the web will enable a new class of applications that progressively enhance on hardware that's barely been an afterthought until now.

> (e.g. the touchscreen on a Pixel or the trackpad on a Surface is a merely a gimmick)

And he conveniently forgets about devices like the Yoga.

In what seems to be a minority opinion, I don't think Apple's rejection of Pointer Events is unreasonable, and do agree with the viewpoint they've put forward – that touch events and mouse events are distinct, and should be treated as such.

That said, they'll probably have to get on board anyway.

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.

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")

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.

Or introduce a whole new hierarchy.

Apple has no benefit in supporting pointer events. The devices they sell only have mice or touch interfaces, which are well-handled by mouse and touch events. There is no benefit to Apple customers to support pointer events, only benefits to developers who think pointer events are "better"

More to the point, developers think that pointer events obviate the need for separate codepaths that accomplish the same thing.

So then we can be pretty sure Apple won't be releasing a laptop/desktop computer with a touch screen?

Seems to me that standard touch events would work fine if I was touching the screen on my Mac. How do pointer events help with that?

Because both the touch events standard assumes that you don't have a mouse, and the mouse events standard assumes that you don't have a touch input. They aren't designed to both be running at the same time.

I can see value in finding a way to expose individual touch points from their new touchpad to JavaScript. We looked at doing something similar in IE, actually, but didn't get around to it in time.

If they want to do that, then they're going to have lots of compatibility problems doing it with Touch Events. Too much code out there expects the presence of Touch Events to mean a touch-only device. So if you enable TE on a laptop, suddenly sites stop working for mouse/track. :-( Pointer Events don't have this problem.

Interesting thought, I'm not sure if PointerEvents would be handled correctly with a trackpad that would have traditionally used as Mouse input either. Seems like the developer would have to know how the trackpad is being used more than anything else since mouse/touch are very different behaviors.

yep, we imagined this would be surfaced as a new event.pointerType value, allowing code to specifically target the device if desired.

This is in part due to feedback from the community: https://code.google.com/p/chromium/issues/detail?id=162757#c...

I'm glad the Chrome team is doing this. Pointer events is a good spec , I hope Apple will do the same eventually.

I'm going against the grain and make the assertion that improving the Touch Events was the better option here. Touch Events are supported by more browsers and devices and already have many of the functional requirements that Pointer Events have.

While it makes sense to have a consistent API, for the foreseeable future there will be three event standards; touch, pointer, and mouse. While if there was focus on an existing standard it would leave web developers with a smaller room for error. A direct result of Blink using the Pointer Event standard is that there will be more web bloat such as jQuery wrappers to abstract interaction.

Most web developers like have experienced the mess of getting touch events and mouse events feeling consistent across different devices and browsers. Throwing more hardware and an extra API into the mix is only going to make things worse.

I welcome the much needed pressure support, for the average web developer and user the result will likely be detrimental. Colour me cynical, each browser has to nail its implementation or we're going to see another messy standard. IE for example still does not support Touch Events, even on WP. This makes front end development painful if you support the device.

This is a complicated set of trade offs and I've argued on both sides of the fence so I can't pretend to imply the decision is at all clear cut. But let me respond to a couple details here.

First, the 'jQuery bloat' you're worried about looked like it was going to happen without Chrome native support: http://blog.jquery.com/2015/02/24/getting-on-point/. One of our goals in revisiting the decision was to avoid frameworks like jQuery having to include such polyfills to Chrome users.

The other thing is that we shouldn't assume Chrome doing Pointer Events means we won't also improve Touch Events. That's a complicated decision influenced in large part by participation by other browser vendors in the standards process around Touch Events.

> IE for example still does not support Touch Events, even on WP.

Yes they do. However, IE11 doesn't support Touch Events on desktop because there is already too much code out there that makes stupid assumptions about Touch Events implying a tablet or phone without a mouse. http://blogs.msdn.com/b/ie/archive/2014/09/05/making-the-web...

MSIE 11 for mobile is still in developer preview mode, and hasn't been released. As for the desktop version, here's caniuse:http://caniuse.com/#feat=touch

I'm unaware that they released a desktop version where they enabled it, I'll have to look into it.

The version of IE with Touch Events (Windows Phone 8.1 Update) is no longer in preview. You can buy retail devices with it on it today, actually.

For the desktop version, see my recent blog post: http://blogs.msdn.com/b/ie/archive/2015/02/24/pointer-events...

Reply on news.ycombinator.com