6 ms·

Apple's continuing opposition is disappointing. The situation with Safari is a worrying echo of Internet Explorer's heyday, with an important player dragging t

by iMark 12y ago

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

o_____________o 12y ago
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.
- matthewmacleod 12y ago
  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?
  - o_____________o 12y ago
    pointer event madness. file selector crash. <option> 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.
    - acdha 12y ago
      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
      - dmethvin 12y ago
        Here are some I'm aware of: https://github.com/jquery/sizzle/issues/290 https://github.com/jquery/sizzle/issues/290 https://github.com/jashkenas/underscore/issues/2081 https://github.com/jashkenas/underscore/issues/2081 https://github.com/jquery/jquery/issues/2145 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.
  - untog 12y ago
    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.
  - streptomycin 12y ago
    http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-Broken-Bad http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-B...
  - csytan 12y ago
    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.
    - grrowl 12y ago
      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 https://github.com/ftlabs/fastclick#when-it-isnt-needed Android Firefox ref: https://bugzilla.mozilla.org/show_bug.cgi?id=941995 https://bugzilla.mozilla.org/show_bug.cgi?id=941995
Igglyboo 12y ago
What is their reasoning for refusing to implement them in WebKit?
- bsimpson 12y ago
  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/023050.html https://lists.webkit.org/pipermail/webkit-dev/2012-December/...
  - rbyers 12y ago
    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.
    - mbrubeck 12y ago
      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.)
      - camhenlin 12y ago
        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.
matthewmacleod 12y ago
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.
- rbyers 12y ago
  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.
  - existencebox 12y ago
    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")
    - mbrubeck 12y ago
      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.
      - 12y ago
camhenlin 12y ago
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"
- tadfisher 12y ago
  More to the point, developers think that pointer events obviate the need for separate codepaths that accomplish the same thing.
- apayan 12y ago
  So then we can be pretty sure Apple won't be releasing a laptop/desktop computer with a touch screen?
  - camhenlin 12y ago
    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?
    - cwyers 12y ago
      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.
- gtjrossi 12y ago
  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.

by iMark 12y ago

o_____________o 12y ago

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.

matthewmacleod 12y ago
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?
- o_____________o 12y ago
  pointer event madness. file selector crash. <option> 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.
  - acdha 12y ago
    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
    - dmethvin 12y ago
      Here are some I'm aware of: https://github.com/jquery/sizzle/issues/290 https://github.com/jquery/sizzle/issues/290 https://github.com/jashkenas/underscore/issues/2081 https://github.com/jashkenas/underscore/issues/2081 https://github.com/jquery/jquery/issues/2145 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.
- untog 12y ago
  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.
- streptomycin 12y ago
  http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-Broken-Bad http://www.raymondcamden.com/2014/09/25/IndexedDB-on-iOS-8-B...
- csytan 12y ago
  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.
  - grrowl 12y ago
    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 https://github.com/ftlabs/fastclick#when-it-isnt-needed Android Firefox ref: https://bugzilla.mozilla.org/show_bug.cgi?id=941995 https://bugzilla.mozilla.org/show_bug.cgi?id=941995

Igglyboo 12y ago

What is their reasoning for refusing to implement them in WebKit?

bsimpson 12y ago
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/023050.html https://lists.webkit.org/pipermail/webkit-dev/2012-December/...
- rbyers 12y ago
  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.
  - mbrubeck 12y ago
    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.)
    - camhenlin 12y ago
      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.

matthewmacleod 12y ago

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.

rbyers 12y ago
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.
- existencebox 12y ago
  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")
  - mbrubeck 12y ago
    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.
    - 12y ago

camhenlin 12y ago

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"

tadfisher 12y ago
More to the point, developers think that pointer events obviate the need for separate codepaths that accomplish the same thing.
apayan 12y ago
So then we can be pretty sure Apple won't be releasing a laptop/desktop computer with a touch screen?
- camhenlin 12y ago
  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?
  - cwyers 12y ago
    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.
gtjrossi 12y ago
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.