My comment on https://www.youtube.com/watch?v=ngBy0H_q-GY

comment.md

Before I watched this, if someone would have asked about why Pointer Events wasn't getting into Chrome, I'd have pointed at Safari. I don't love that reason, but it makes sense with their current dominance on mobile. However, I don't necessarily agree, I think if every other browser implemented them, they'd come around. That's tended to be true on the web for the last 20 years (Old IEs, webgl, innerHTML, video codecs when hardware is present, etc)

As far as the main issues brought up here, which I hopefully have fairly summarized (in one sentence each, lol, sry) below, I don't see them as entirely compelling for dropping PE altogether, especially since so many real-world folks (jQuery, Dojo, IE-y people) like the unification quite a bit.

1. Hit tests (with or without capture) are expensive and bad for performance

From what I can read from the previous calls and conversations[0] about this, it's less of an issue than it seems. From those conversations, it seemed like hit tests weren't cached, and Chrome at the time was interested in implementing a cache for them. I saw the numbers '0.15ms on average hardware' in the ms article, which isn't nothing, but is only 0.9% of your frame budget in a 60fps situation. [1]

It also seems similar to drag and drop situations, where you need to do a healthy amount of hit testing for making your UI respond to where you're dropping. So these problems seem to want to exist other places as well, regardless of whether they're in PE or not.

There are also perf concerns around both models (touch and PE) running simultaneously, and those are fair, but probably short-lived, warnable, and ultimately something developers would know to avoid.

2. Sometimes you want to treat touch events specially (example given was swiping)

Some things become a little less "direct" with PE, but you can still very much differentiate touch from mouse events. The pointerType attribute tells you exactly the type of interaction and you could branch on that just as easily as two different literal types of events.

More importantly, though, is that the entire reason that developers really like PE, and are excited about them, is that in so many cases you do want unified events. As far as I know, that desire was the motivation for their existence, and seems like a reasonable default.

So I definitely don't love this reason (it does seem like this might have been more of an 'off the top of the head' comment than a real deciding factor in Chrome pulling PE, but seemed worth mentioning).

3. "Pull to Refresh" is impossible

This is definitely true, but seems like something that the people involved are willing to fix. From what I read in those discussions, we could compliment the PE spec with a spec for "Negative Scroll Behaviour of a Container" (NSBoaC, beautiful).

Scroll event dispatch in pointer events is currently specified as being asynchronous, which is a very good thing because it means that your UI thread does not jank due to heavy scroll events, but it means you can’t manually fiddle with scrolls with pointer events which is how pull to refresh is normally implemented. However, from what I saw, Jacob (the PE editor) has stated that he has no problem implementing an opt-in sync event dispatch to the spec.

Let's do that!

4. "We already have Touch Events" (noted as the "main" reason)

We don't have unified touch events. They're different in chrome than they are other places. They're not in IE, but since everyone else implemented, they're caving. We could do the same trick with Safari!

---

Obviously I'm jumping in to this party kind of late, but hopefully from a fairly neutral place. I get the not-in-Safari argument, and I understand being scared about performance in the immediate term, but I can't help but feel like Chrome is running away from a fight that they would have normally fought in the past.

I can't think of a worse place to discuss this than in youtube comments (ok maybe a w3 mailing list), so feel free to answer out of bound (or not at all, I'm not owed anything :D).

<3z Alex Fellow Undergarment Flipper

[0] http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0072.html , https://code.google.com/p/chromium/issues/detail?id=162757 [1] http://blogs.msdn.com/b/ie/archive/2014/09/05/making-the-web-just-work-with-any-input.aspx

A bunch of folks including Dojo and jQuery devs spent time in a meeting where we discussed many of the objections with Rick Byers from Google. Before saying anything else I want to be sure to thank Rick for being so patient and attempting to address all the issues, which turn out to be the same ones mentioned in the video.

Most of us left the meeting thinking that none of these issues were impediments to Pointer Events being adopted. Performance for example is a red herring, you just need a simple cache to avoid some recalculation. The people invested in Pointer Events are quite willing to discuss enhancements that would allow better handling of things like pull-to-refresh.

In contrast, changes to Touch Events are really difficult to make, and there are plenty of variations across platforms. Many "enhancements" risk breaking the web. Apple doesn't seem interested in discussing the matter anyway so it's hard to argue that there is any future in enhancing the current de-facto implementations when Apple won't participate.

Basically it comes down to Colin Snover's question from the meeting: "Why is Chrome+IE+Firefox not enough for PE, but Chrome+Firefox enough for TE extensions?"

I can't think of a worse place to discuss this than in youtube comments (ok maybe a w3 mailing list),

If only Github gave notifications on gist comments and mentions. 💩

As a developer on the web it's frustrating to see this going round and round constantly and the argument constantly coming back to "We already have TE" but people neglecting to acknowledge that TE doesn't have cross-browser unification either (which is well documented in @dmethvin's linked gdoc).

And since when was it a good thing to drive a feature by just implementing it into a browser engine? Isn't that how we ended up with the mess that was 2001 - 2007 where we had different implementations that today we're still paying the price for?

“What exactly were your concerns?”

In addition to everything everyone else has raised in this thread and elsewhere…

“We keep things short so we can't cover all the nuances”

Technical discussions about things like “performance” and “richness” are all nuance. Our standards go so far as to define words like “MAY”, “SHOULD”, and “MUST” to account for this. If the format chosen for a technical program is incapable of describing topics with accuracy and necessary attention to detail, the format needs to change. It doesn’t even need to be longer, it just needs to give facts and be clear when presenters are just speaking their personal opinions. Treating opinion as fact is the territory of cable news pundits, not respected technical evangelists.

“the show presents our views, not necessarily all views”

Since this was posted on the Google Developers YouTube channel, it’s presented as Google’s view, not the views of two individuals. Since it isn’t an entertainment channel, people will expect that the information they are receiving from it is accurate. However, this video presents information on Pointer Events in a way that is quite misleading.

For example, let’s switch it and say this episode was about the ES5 iterator functions like Array#forEach, instead of Pointer Events. To paraphrase:

- “Array.prototype.forEach is great! It lets you act directly on all the items in an array!”

• “Yaay!”
• “Except the performance is really bad. And it doesn’t let you do things like break out of the loop early that you can do with a for loop.”
• “Oh no!”

I think you can agree these are some pretty silly reasons not to implement forEach, but they would actually be more reasonable than what this video says about PE, since on Android 4.4 a forEach loop is something like 75% slower than a for loop, whereas PE adds a worst-case 0.93% overhead for hit testing (and touch events are much more awful to deal with than a for loop!).

“we haven’t attempted to mislead”

It may not have been the intent, but the information in the video is nevertheless misleading, contradicts the facts, and promotes ideas that had been debunked before the episode was published. That several people have been compelled to speak against it makes that fairly clear.

I feel that offering a follow-up that provides clear technical information and corrects at least these things is owed to the viewers and the Web platform:

1. The performance “problem” with hit testing was heavily dramatised as though it’s crushingly awful, even though it’s actually less than 1% of a 60fps frame budget—despite not being fully optimised—on today’s slower mobile devices. Even Rick Byers has openly admitted that performance of hit testing really isn’t a problem.
2. The swiping comment implied that Pointer Events don’t enable you to do actions only on touch devices, which is patently untrue (just check the pointerType property).
3. It was claimed that TE always provide a richer experience and implied that there is no way to change PE to make it work with those TE use cases, like pull-to-refresh. In most cases, Pointer Events enables better UX by allowing better control over native scrolling (with touch-action) and by allowing scrolling to run outside the main UI thread (reduced jank). In the only case where TE has an advantage, the PE editor has stated repeatedly he is willing to figure out a way to make it possible with PE.

“Our goal is to…drive conversation and debate”

This has already been discussed and debated ad nauseam. We’ve discussed it on the bug tracker. We’ve discussed it on the mailing list. We’ve had meetings on Skype. Over 300 people have starred and commented on https://code.google.com/p/chromium/issues/detail?id=162757 to say that they want Pointer Events. I only see the folks at Google continuing to produce things like this video that propagate falsehoods about the PE spec and ignore the desire of the overwhelming majority of the Web development community to make Pointer Events work.

In sum, I think that Google’s Rick Byers said it best:

I'm all for having legitimate technical debate about what's best for the web. But if you stoop to misleading your [viewers] to attempt to make your argument appear stronger it only works against our efforts to improve the web together.

I hope that in the future, technical accuracy will not be sacrificed for the sake of “the format”, since I think this series could be a valuable resource for enabling people to remain up-to-date with emerging standards. I also hope they will publish a correction to the things in this video that are not true, either with added annotations, or as a separate follow-up video, or both.