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?
Intent to Implement: Pointer Events in Chrome
21–30 of 45 posts
Re: Intent to Implement: Pointer Events in Chrome
#22Earlier 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?
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.
Re: Intent to Implement: Pointer Events in Chrome
#23Earlier 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?
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
Re: Intent to Implement: Pointer Events in Chrome
#24Earlier quoted context omitted.
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.
Re: Intent to Implement: Pointer Events in Chrome
#25Apple'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"
So then we can be pretty sure Apple won't be releasing a laptop/desktop computer with a touch screen?
Re: Intent to Implement: Pointer Events in Chrome
#26Apple'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"
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.
Re: Intent to Implement: Pointer Events in Chrome
#27Earlier quoted context omitted.
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"
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.
Re: Intent to Implement: Pointer Events in Chrome
#28Earlier quoted context omitted.
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"
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?
Re: Intent to Implement: Pointer Events in Chrome
#29Earlier 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.
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.
Re: Intent to Implement: Pointer Events in Chrome
#30Earlier quoted context omitted.
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.