Intent to Implement: Pointer Events in Chrome
groups.google.com
Intent to Implement: Pointer Events in Chrome
1–10 of 45 posts
Re: Intent to Implement: Pointer Events in Chrome
#2This is in part due to feedback from the community: https://code.google.com/p/chromium/issues/detail?id=162757#c...
Re: Intent to Implement: Pointer Events in Chrome
#3Apple'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.
Re: Intent to Implement: Pointer Events in Chrome
#4Apple'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…
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.
Re: Intent to Implement: Pointer Events in Chrome
#5Apple'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…
What is their reasoning for refusing to implement them in WebKit?
Re: Intent to Implement: Pointer Events in Chrome
#6Apple'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…
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/...
Re: Intent to Implement: Pointer Events in Chrome
#7Apple'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…
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.
Re: Intent to Implement: Pointer Events in Chrome
#8Apple'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…
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?
Re: Intent to Implement: Pointer Events in Chrome
#9Earlier 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…
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.
Re: Intent to Implement: Pointer Events in Chrome
#10Apple'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…
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.