Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intent to Implement: Pointer Events in Chrome

groups.google.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Intent to Implement: Pointer Events in Chrome

#31

Post by gtjrossi »

camhenlin wrote: post #27
gtjrossi wrote: post #26

Earlier quoted context omitted.

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…

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.

Re: Intent to Implement: Pointer Events in Chrome

#32

Post by bsimpson »

rbyers wrote: post #9
bsimpson wrote: post #6

Earlier quoted context omitted.

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 the…

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.

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.

Re: Intent to Implement: Pointer Events in Chrome

#33

Post by existencebox »

rbyers wrote: post #10
matthewmacleod wrote: post #7

Earlier quoted context omitted.

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

Re: Intent to Implement: Pointer Events in Chrome

#34

Post by mbrubeck »

camhenlin wrote: post #29
mbrubeck wrote: post #12

Earlier quoted context omitted.

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…

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.

Re: Intent to Implement: Pointer Events in Chrome

#35

Post by mbrubeck »

existencebox wrote: post #33
rbyers wrote: post #10

Earlier quoted context omitted.

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 chan…

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.

Re: Intent to Implement: Pointer Events in Chrome

#36

Post by camhenlin »

mbrubeck wrote: post #34
camhenlin wrote: post #29

Earlier quoted context omitted.

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 pa…

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

Re: Intent to Implement: Pointer Events in Chrome

#37

Post by pippy »

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.

Re: Intent to Implement: Pointer Events in Chrome

#38

Post by grrowl »

csytan wrote: post #22
matthewmacleod wrote: post #8

Earlier quoted context omitted.

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?

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

Re: Intent to Implement: Pointer Events in Chrome

#39

Post by rbyers »

pippy wrote: post #37

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 exist…

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.

Re: Intent to Implement: Pointer Events in Chrome

#40

Post by dmethvin »

acdha wrote: post #23
o_____________o wrote: post #11

Earlier quoted context omitted.

pointer event madness. file selector crash. 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 o…

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.

Post reply on HN