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

11–20 of 45 posts

Re: Intent to Implement: Pointer Events in Chrome

#11

Post by o_____________o »

matthewmacleod wrote: post #8
o_____________o wrote: post #4

Earlier quoted context omitted.

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. 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.

Re: Intent to Implement: Pointer Events in Chrome

#12

Post by mbrubeck »

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.

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

Re: Intent to Implement: Pointer Events in Chrome

#13

Post by amyjess »

bsimpson wrote: post #6
Igglyboo wrote: post #5

Earlier quoted context omitted.

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

> (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.

Re: Intent to Implement: Pointer Events in Chrome

#14

Post by integraton »

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 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.

Re: Intent to Implement: Pointer Events in Chrome

#15

Post by mbrubeck »

integraton wrote: post #14
rbyers wrote: post #9

Earlier quoted context omitted.

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 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.

Re: Intent to Implement: Pointer Events in Chrome

#16

Post by integraton »

mbrubeck wrote: post #15
integraton wrote: post #14

Earlier quoted context omitted.

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.

Re: Intent to Implement: Pointer Events in Chrome

#17

Post by camhenlin »

iMark wrote: post #3

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

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"

Re: Intent to Implement: Pointer Events in Chrome

#18

Post by untog »

matthewmacleod wrote: post #8
o_____________o wrote: post #4

Earlier quoted context omitted.

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?

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.

Re: Intent to Implement: Pointer Events in Chrome

#19

Post by tadfisher »

camhenlin wrote: post #17
iMark wrote: post #3

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

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.
Post reply on HN