4 ms·

Apple stifling the work of web standard

57 points by sberder 12y ago

mikhailt 12y ago
I'm struggling to understand how Apple is stifling this standard. I don't even know why Apple is being given this much power in the first place. Yes, the article mentioned some but it cannot be the market share and some developer bias. Apple doesn't have much of a market share in the first place. They have what <8% of the PC market share and maybe ~10% of the mobile market share? Google owns 80% of the mobile market share, they have far more influence than Apple. Google managed to get stuff done via its SPDY2 work to the point that the HTTP/2 standard adopted most of their work, without any help from Apple. So what's the problem here? I know it is not the same analogy as the Pointer Event/Touch Event but still, it is possible. > Too many times, we’ve seen browser vendors with the best intentions fall victim to Apple’s reluctance to work with standards bodies and WebKit’s dominance on mobile devices. We cannot let this continue to happen. I totally agree but Apple's not required to work with any standard bodies. Focus on getting your standard out and then call on Apple for failing to support it when the rest of the market supports it. Let Apple realize they can't get away with not being involved. Also, WebKit is an open platform. Apple does not own it completely and look at Google's Blink fork along with Opera helping out. Blink probably now has more users than Webkit.
- cmurf 12y ago
  You've got the mobile browser market share almost backwards. https://www.netmarketshare.com/browser-market-share.aspx?qprid=1&qpcustomb=1 https://www.netmarketshare.com/browser-market-share.aspx?qpr... And then there's this. http://venturebeat.com/2014/12/03/why-do-ios-users-buy-more-stuff-than-android-users-because-they-have-more-money/ http://venturebeat.com/2014/12/03/why-do-ios-users-buy-more-... The reality is that Apple has significant market share, and Apple doesn't really follow very often. Ever heard if NIH and the reality distortion field?
  - mikhailt 12y ago
    > You've got the mobile browser market share almost backwards. No, I didn't. I said nothing about mobile browser share. I'm talking about the market share of the mobile "device" share. Most recent IDC report (there isn't the best one, every one has their own bias but I'm just linking this because it is the most recent) : http://www.idc.com/getdoc.jsp?containerId=prUS25450615 http://www.idc.com/getdoc.jsp?containerId=prUS25450615 Apple has ~15% of the market share as of 2014. Android is at ~82%. Heck, your venturebeat.com link mentioned it as well. The second link doesn't explain at all why Apple should decide how a standard should work. Are you telling me that a single company that has the most people with money should be the one that determines how the standard works? That's like saying the richest candidate should win the presidency because he has the most voters that has money (actually, that actually feels like it most of the time in US). > Ever heard if NIH and the reality distortion field? What's NIH? I know National Institute of Health but I don't understand how they're related here. Yes, I've heard of RDF. These W3 folks should not even care about it and is smarter than most people, they shouldn't be falling for it and focus on getting standards out based on technical merits, not marketing.
    - deleted 12y ago
      [deleted]
    - __david__ 12y ago
      > What's NIH? "Not Invented Here": https://en.wikipedia.org/wiki/Not_Invented_Here https://en.wikipedia.org/wiki/Not_Invented_Here
      - mikhailt 12y ago
        Ah, thanks. I appreciate the link.
    - millstone 12y ago
      Device sales and operating systems are irrelevant to web standards: what matters is what browser visitors use. Google has a problem here - where Android is growing fastest (China, India, etc) people don't use mobile Chrome. China has the most Android users, and UC Browser, QQ Browser, and the old no-longer-supported Android browser are all far more popular than Chrome on mobile devices. https://www.techinasia.com/uc-browser-beats-chrome-safari-china-india-pakistan-ranked-4th-worldwide/ https://www.techinasia.com/uc-browser-beats-chrome-safari-ch...
- deleted 12y ago
  [deleted]
- nemothekid 12y ago
  The Google's "80% of the mobile market share" is misleading, when a majority of those phones don't complete with the iPhone and aren't developer targets. Its like saying "8-bit CPUs are 90% of the CPU market, so I don't get why anyone cares about Intel". Android had well over double Apple's marketshare in 2012 when FB bought Instagram for $1B, and they had yet to (or just had) released their Android app. Despite having 80% marketshare, Apple's App store generated more revenue than the Play market last quarter[1]. When the vast majority of mobile revenue is generated by iPhone users, that means if it doesn't work on iOS, it doesn't work at all - 80% marketshare be damned. When Apple holds the most important card - revenue - its not hard to see that they are in the best position for stifling standards. If you are a developer are you going to sacrifice your revenue for standards, or play by Apple's rules? >Google managed to get stuff done via its SPDY2 work to the point that the HTTP/2 standard adopted most of their work, And it was something that could be deployed to the vast majority of users without a single finger being lifted from anyone outside Google. >I totally agree but Apple's not required to work with any standard bodies. Focus on getting your standard out and then call on Apple for failing to support it when the rest of the market supports it. Unfortunately most standards don't work this way. When standard bodies were left to their own devices, we got XHTML. Most standards seem to work like SPDY - one or two companies (Google, FB) use their market position to rollout a huge change to large number of clients and then make that the standard while everyone else cries about binary headers. In the PointerEvents case, the company with market position is Apple. I'd imagine the best thing to do is commented on the article. Create a Polyfill, and if PointerEvents are better than the rest, developers will naturally use them. Eventually given the huge amount of developers on the polyfill Apple may be inclined to make it native. [1]http://www.techspot.com/news/58456-google-play-vs-app-store-downloads.html http://www.techspot.com/news/58456-google-play-vs-app-store-...
  - smosher_ 12y ago
    > When the vast majority of mobile revenue is generated by iPhone users, that means if it doesn't work on iOS, it doesn't work at all - 80% marketshare be damned. How does this matter to Google or the W3C exactly? I don't buy this reasoning. The CPU analogy doesn't work either, since everyone depends on a number of different processors, with Intel approaching 100% representation among individuals—this doesn't hold for iOS in the mobile market, where people typically depend on one phone. That said, iOS might have stronger representation among the people who depend on mobile browsing than the market share numbers suggest (but that needs measuring.) My guess is that even as low as 20% of mobile is sufficiently significant to Google (whose employees all seem to have MBPs) and two major vendors is likewise to the standards committee. > I'd imagine the best thing to do is commented on the article. Create a Polyfill, and if PointerEvents are better than the rest, developers will naturally use them. Eventually given the huge amount of developers on the polyfill Apple may be inclined to make it native. Very yes. I'm not completely sold on pointer events but the tactic encourages real-world exploration.
- millstone 12y ago
  The fact that Android dominates global mobile phone sales does not mean that Google dominates the mobile market. For example, the biggest market for Android phones is in China - and yet the great majority of these phones have Baidu as the default search engine and do not ship with Google Play services. How can Google be said to own this market? But device sales are not even the relevant question - web traffic is. And there, iOS and Android appear about even. For example, see Wikipedia's hits [1]: iOS across mobile and tablet is about 34 billion hits per year, compared to 33.5 for Android. And that's before we even get to the notion of influence. iOS 8 adoption is at 73%, Android 5.0 is at 1.6%. Apple evidently has far more influence over iOS users than Google does over Android users. That means that Apple's adoption of a mobile web standard will have a much greater impact. [1]: https://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm https://stats.wikimedia.org/wikimedia/squids/SquidReportClie...
zobzu 12y ago
Seem both Apple and Google are doing this. (as in "stifling")
- mikhailt 12y ago
  Microsoft is adopting support for Touch Events:https://status.modern.ie/touchevents?term=touch https://status.modern.ie/touchevents?term=touch
  - camhenlin 12y ago
    Which is hilarious after talking to a few IE team leads last summer, who told me I should write all of my code using pointer events and polyfill browsers with touchevents, just so I could support their mobile browser with no market share.
camhenlin 12y ago
I completely disagree. Apple supported the defacto standard for handling touch input (http://www.w3.org/TR/touch-events/ http://www.w3.org/TR/touch-events/) before any other browser vendor, and Google followed them very quickly. The w3c decision to abandon touch events and pursue pointer events was only after Apple submitted to the w3c patent advisory group that they held patents on the standard (with no indication of requiring royalty -- and no indication of going after other browser vendors supporting touch events such as Google). Furthermore, what is a pointer event going to do on an Apple or Google platform? Apple devices only support touch and mice as of this writing -- why do they need pointer events, which adds things such as stylus support with tilt? What would be the purpose of implementing that? Same goes for Google, only Android products I can think of with stylus support are the Samsung Note series, and I don't think those even support the special features of pointer events (I'm thinking tilt and pressure). Anyways, if you feel that strongly about it, you can use pointer events, and polyfill them on Apple platforms with this: https://github.com/jquery/PEP https://github.com/jquery/PEP Or you can keep using touch events and polyfill them on to platforms that only support pointer events with this: https://github.com/CamHenlin/TouchPolyfill/ https://github.com/CamHenlin/TouchPolyfill/ (disclaimer: I helped write this one :) )
- rockdoe 12y ago
  with no indication of requiring royalty Irrelevant. Did they give a promise not to do so? If not, using that API would be commercial suicide.
  - camhenlin 12y ago
    Except Google began using it immediately and did so for years before the patents were disclosed, and the w3c abandoned the standard prior to even asking about royalties. I think the w3c is at fault for the fracture in the standards more than anyone else. It's my understanding that Apple holds patents on the canvas standards that they do not require royalties for as well
- TwoBit 12y ago
  So Apple should support only standards that directly benefit their hardware? That's exactly problem OP is talking about.
sitharus 12y ago
I think the key thing here is Google "following". Google have their own fork of WebKit, they can implement pointer events if they so choose, and they also have a far, far larger share of the desktop browser market. Except for on mobile Apple are a minor player, and even on mobile Google is still the major player.
panic 12y ago
Are pointer events actually a good way to write high-quality web apps? Maybe Apple and Google have reasons for opposing the standard.
- ygra 12y ago
  They unify the way you deal with mouse, touch, stylus and potentially other pointing devices. While this can mean that developers using only one of those in a single application still have less to remember, it's mostly meant for actuall being able to write applications that support both touch and mouse, for example. For Microsoft, with a device that supports all three modes of pointer interaction, it's actually quite important if it's even possible (remember, you can write Windows 8 apps with HTML, too – and no one's going to be happy if your UI stops working with a finger or stylus just because the developer forgot to replicate the logic three times). If you only deal with touch input then pointer events isn't more complicated than touch events, but with the added bonus that things work as expected with a mouse or stylus, too (except multi-touch, of course). Apple in this respect doesn't really need to care, because no one uses iOS with another pointing device than a finger (or a capacitive stylus, which, from a software standpoint, is just a thinner finger).
bsimpson 12y ago
I've (privately) heard suspicions by other browser vendors that Apple stopped innovating on the web when the App Store blew up because they now have a commercial disincentive to support a open, vibrant web. They're accused of intentionally dragging their feet on new standards, only capitulating _after_ something has succeeded without them when their lack of support makes them look broken.
franciscop 12y ago
From the specification linked in the article: > The normalized pressure of the pointer input in the range of [0,1], where 0 and 1 represent the minimum and maximum pressure the hardware is capable of detecting, respectively. For hardware that does not support pressure, including but not limited to mouse, the value MUST be 0.5 when in the active buttons state and 0 otherwise. What kind of non-sense is this? It's like saying 0 is white and 1 is black, but when a grayscale is not available, 0.5 is black.
- ygra 12y ago
  It means that for pressure-sensitive applications mouse or touch input behaves as if the stylus was used with moderate pressure. Which makes sense if you consider something like a drawing application where the pressure makes the brush larger. You neither want no brush at all (0 pressure), nor something blown out of proportion (1) but rather what is similar to when using a pen normally. (Full pressure for a stylus is usually a lot of force that's rarely, if ever, used.)
- qnaal 12y ago
  The idea seems be[1] that 'pressing super hard' should be easily distinguishable from 'pressing a normal amount'- which is understandable, but I don't know how preferable to announcing that pressure simply isn't supported... [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20109 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20109
thomasfoster96 12y ago
In general, browser vendors all have a history of doing things that stifle standards progress. Pointer Events (which is a good idea) has been stifled, as have lots of other relatively good or promising ideas, such as Web SQL, WebCL, etc. I'm sure browser developers have legitimate concerns about these emerging standards, but I doubt any of these concerns have warranted dumping these ideas.
bonn1 12y ago
It's true and obvious that Apple slowed down innovating the web since the core of their business is iOS and apps. They should not have an interest in a fast innovating web that gets on par with native apps which is their main lock-in for iOS, just like Microsoft did 15 years ago. They only speed up their rendering engine and JS core but don't try to help on standards improving the web experience. BUT: I doubt this pointer event thing is a good example for their strategy because it's really just a nice-to-have feature for the Surface and the Note series which is for my taste a too small target to justify a standard. A good example for Apple reluctance to innovate the web is CSS Flexbox. CSS Flexbox is the best positioning standard I encountered, every vendor supports it, only Apple still prefixes it with -webkit. Another example is their reluctance to make WKWebview fully workable, since months there is still a bug which prevents WKWebview loading local files, the bug was already fixed in an early beta of iOS 8 but then they put it again in. WKWebKit is way more performant than UIWebview and can produce butter smooth HTML5 apps with Cordova/Phonegap but this one bug makes it hard (people already build local web servers to work around this problem).
- deleted 12y ago
  [deleted]

57 points by sberder 12y ago

I'm struggling to understand how Apple is stifling this standard. I don't even know why Apple is being given this much power in the first place. Yes, the article mentioned some but it cannot be the market share and some developer bias. Apple doesn't have much of a market share in the first place. They have what <8% of the PC market share and maybe ~10% of the mobile market share? Google owns 80% of the mobile market share, they have far more influence than Apple. Google managed to get stuff done via its SPDY2 work to the point that the HTTP/2 standard adopted most of their work, without any help from Apple. So what's the problem here? I know it is not the same analogy as the Pointer Event/Touch Event but still, it is possible. > Too many times, we’ve seen browser vendors with the best intentions fall victim to Apple’s reluctance to work with standards bodies and WebKit’s dominance on mobile devices. We cannot let this continue to happen. I totally agree but Apple's not required to work with any standard bodies. Focus on getting your standard out and then call on Apple for failing to support it when the rest of the market supports it. Let Apple realize they can't get away with not being involved. Also, WebKit is an open platform. Apple does not own it completely and look at Google's Blink fork along with Opera helping out. Blink probably now has more users than Webkit.

cmurf 12y ago
You've got the mobile browser market share almost backwards. https://www.netmarketshare.com/browser-market-share.aspx?qprid=1&qpcustomb=1 https://www.netmarketshare.com/browser-market-share.aspx?qpr... And then there's this. http://venturebeat.com/2014/12/03/why-do-ios-users-buy-more-stuff-than-android-users-because-they-have-more-money/ http://venturebeat.com/2014/12/03/why-do-ios-users-buy-more-... The reality is that Apple has significant market share, and Apple doesn't really follow very often. Ever heard if NIH and the reality distortion field?
- mikhailt 12y ago
  > You've got the mobile browser market share almost backwards. No, I didn't. I said nothing about mobile browser share. I'm talking about the market share of the mobile "device" share. Most recent IDC report (there isn't the best one, every one has their own bias but I'm just linking this because it is the most recent) : http://www.idc.com/getdoc.jsp?containerId=prUS25450615 http://www.idc.com/getdoc.jsp?containerId=prUS25450615 Apple has ~15% of the market share as of 2014. Android is at ~82%. Heck, your venturebeat.com link mentioned it as well. The second link doesn't explain at all why Apple should decide how a standard should work. Are you telling me that a single company that has the most people with money should be the one that determines how the standard works? That's like saying the richest candidate should win the presidency because he has the most voters that has money (actually, that actually feels like it most of the time in US). > Ever heard if NIH and the reality distortion field? What's NIH? I know National Institute of Health but I don't understand how they're related here. Yes, I've heard of RDF. These W3 folks should not even care about it and is smarter than most people, they shouldn't be falling for it and focus on getting standards out based on technical merits, not marketing.
  - deleted 12y ago
    [deleted]
  - __david__ 12y ago
    > What's NIH? "Not Invented Here": https://en.wikipedia.org/wiki/Not_Invented_Here https://en.wikipedia.org/wiki/Not_Invented_Here
    - mikhailt 12y ago
      Ah, thanks. I appreciate the link.
  - millstone 12y ago
    Device sales and operating systems are irrelevant to web standards: what matters is what browser visitors use. Google has a problem here - where Android is growing fastest (China, India, etc) people don't use mobile Chrome. China has the most Android users, and UC Browser, QQ Browser, and the old no-longer-supported Android browser are all far more popular than Chrome on mobile devices. https://www.techinasia.com/uc-browser-beats-chrome-safari-china-india-pakistan-ranked-4th-worldwide/ https://www.techinasia.com/uc-browser-beats-chrome-safari-ch...
deleted 12y ago
[deleted]
nemothekid 12y ago
The Google's "80% of the mobile market share" is misleading, when a majority of those phones don't complete with the iPhone and aren't developer targets. Its like saying "8-bit CPUs are 90% of the CPU market, so I don't get why anyone cares about Intel". Android had well over double Apple's marketshare in 2012 when FB bought Instagram for $1B, and they had yet to (or just had) released their Android app. Despite having 80% marketshare, Apple's App store generated more revenue than the Play market last quarter[1]. When the vast majority of mobile revenue is generated by iPhone users, that means if it doesn't work on iOS, it doesn't work at all - 80% marketshare be damned. When Apple holds the most important card - revenue - its not hard to see that they are in the best position for stifling standards. If you are a developer are you going to sacrifice your revenue for standards, or play by Apple's rules? >Google managed to get stuff done via its SPDY2 work to the point that the HTTP/2 standard adopted most of their work, And it was something that could be deployed to the vast majority of users without a single finger being lifted from anyone outside Google. >I totally agree but Apple's not required to work with any standard bodies. Focus on getting your standard out and then call on Apple for failing to support it when the rest of the market supports it. Unfortunately most standards don't work this way. When standard bodies were left to their own devices, we got XHTML. Most standards seem to work like SPDY - one or two companies (Google, FB) use their market position to rollout a huge change to large number of clients and then make that the standard while everyone else cries about binary headers. In the PointerEvents case, the company with market position is Apple. I'd imagine the best thing to do is commented on the article. Create a Polyfill, and if PointerEvents are better than the rest, developers will naturally use them. Eventually given the huge amount of developers on the polyfill Apple may be inclined to make it native. [1]http://www.techspot.com/news/58456-google-play-vs-app-store-downloads.html http://www.techspot.com/news/58456-google-play-vs-app-store-...
- smosher_ 12y ago
  > When the vast majority of mobile revenue is generated by iPhone users, that means if it doesn't work on iOS, it doesn't work at all - 80% marketshare be damned. How does this matter to Google or the W3C exactly? I don't buy this reasoning. The CPU analogy doesn't work either, since everyone depends on a number of different processors, with Intel approaching 100% representation among individuals—this doesn't hold for iOS in the mobile market, where people typically depend on one phone. That said, iOS might have stronger representation among the people who depend on mobile browsing than the market share numbers suggest (but that needs measuring.) My guess is that even as low as 20% of mobile is sufficiently significant to Google (whose employees all seem to have MBPs) and two major vendors is likewise to the standards committee. > I'd imagine the best thing to do is commented on the article. Create a Polyfill, and if PointerEvents are better than the rest, developers will naturally use them. Eventually given the huge amount of developers on the polyfill Apple may be inclined to make it native. Very yes. I'm not completely sold on pointer events but the tactic encourages real-world exploration.
millstone 12y ago
The fact that Android dominates global mobile phone sales does not mean that Google dominates the mobile market. For example, the biggest market for Android phones is in China - and yet the great majority of these phones have Baidu as the default search engine and do not ship with Google Play services. How can Google be said to own this market? But device sales are not even the relevant question - web traffic is. And there, iOS and Android appear about even. For example, see Wikipedia's hits [1]: iOS across mobile and tablet is about 34 billion hits per year, compared to 33.5 for Android. And that's before we even get to the notion of influence. iOS 8 adoption is at 73%, Android 5.0 is at 1.6%. Apple evidently has far more influence over iOS users than Google does over Android users. That means that Apple's adoption of a mobile web standard will have a much greater impact. [1]: https://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm https://stats.wikimedia.org/wikimedia/squids/SquidReportClie...

zobzu 12y ago

Seem both Apple and Google are doing this. (as in "stifling")

mikhailt 12y ago
Microsoft is adopting support for Touch Events:https://status.modern.ie/touchevents?term=touch https://status.modern.ie/touchevents?term=touch
- camhenlin 12y ago
  Which is hilarious after talking to a few IE team leads last summer, who told me I should write all of my code using pointer events and polyfill browsers with touchevents, just so I could support their mobile browser with no market share.

camhenlin 12y ago

I completely disagree. Apple supported the defacto standard for handling touch input (http://www.w3.org/TR/touch-events/ http://www.w3.org/TR/touch-events/) before any other browser vendor, and Google followed them very quickly. The w3c decision to abandon touch events and pursue pointer events was only after Apple submitted to the w3c patent advisory group that they held patents on the standard (with no indication of requiring royalty -- and no indication of going after other browser vendors supporting touch events such as Google). Furthermore, what is a pointer event going to do on an Apple or Google platform? Apple devices only support touch and mice as of this writing -- why do they need pointer events, which adds things such as stylus support with tilt? What would be the purpose of implementing that? Same goes for Google, only Android products I can think of with stylus support are the Samsung Note series, and I don't think those even support the special features of pointer events (I'm thinking tilt and pressure). Anyways, if you feel that strongly about it, you can use pointer events, and polyfill them on Apple platforms with this: https://github.com/jquery/PEP https://github.com/jquery/PEP Or you can keep using touch events and polyfill them on to platforms that only support pointer events with this: https://github.com/CamHenlin/TouchPolyfill/ https://github.com/CamHenlin/TouchPolyfill/ (disclaimer: I helped write this one :) )

rockdoe 12y ago
with no indication of requiring royalty Irrelevant. Did they give a promise not to do so? If not, using that API would be commercial suicide.
- camhenlin 12y ago
  Except Google began using it immediately and did so for years before the patents were disclosed, and the w3c abandoned the standard prior to even asking about royalties. I think the w3c is at fault for the fracture in the standards more than anyone else. It's my understanding that Apple holds patents on the canvas standards that they do not require royalties for as well
TwoBit 12y ago
So Apple should support only standards that directly benefit their hardware? That's exactly problem OP is talking about.

sitharus 12y ago

I think the key thing here is Google "following". Google have their own fork of WebKit, they can implement pointer events if they so choose, and they also have a far, far larger share of the desktop browser market. Except for on mobile Apple are a minor player, and even on mobile Google is still the major player.

panic 12y ago

Are pointer events actually a good way to write high-quality web apps? Maybe Apple and Google have reasons for opposing the standard.

ygra 12y ago
They unify the way you deal with mouse, touch, stylus and potentially other pointing devices. While this can mean that developers using only one of those in a single application still have less to remember, it's mostly meant for actuall being able to write applications that support both touch and mouse, for example. For Microsoft, with a device that supports all three modes of pointer interaction, it's actually quite important if it's even possible (remember, you can write Windows 8 apps with HTML, too – and no one's going to be happy if your UI stops working with a finger or stylus just because the developer forgot to replicate the logic three times). If you only deal with touch input then pointer events isn't more complicated than touch events, but with the added bonus that things work as expected with a mouse or stylus, too (except multi-touch, of course). Apple in this respect doesn't really need to care, because no one uses iOS with another pointing device than a finger (or a capacitive stylus, which, from a software standpoint, is just a thinner finger).

bsimpson 12y ago

I've (privately) heard suspicions by other browser vendors that Apple stopped innovating on the web when the App Store blew up because they now have a commercial disincentive to support a open, vibrant web. They're accused of intentionally dragging their feet on new standards, only capitulating _after_ something has succeeded without them when their lack of support makes them look broken.

franciscop 12y ago

From the specification linked in the article: > The normalized pressure of the pointer input in the range of [0,1], where 0 and 1 represent the minimum and maximum pressure the hardware is capable of detecting, respectively. For hardware that does not support pressure, including but not limited to mouse, the value MUST be 0.5 when in the active buttons state and 0 otherwise. What kind of non-sense is this? It's like saying 0 is white and 1 is black, but when a grayscale is not available, 0.5 is black.

ygra 12y ago
It means that for pressure-sensitive applications mouse or touch input behaves as if the stylus was used with moderate pressure. Which makes sense if you consider something like a drawing application where the pressure makes the brush larger. You neither want no brush at all (0 pressure), nor something blown out of proportion (1) but rather what is similar to when using a pen normally. (Full pressure for a stylus is usually a lot of force that's rarely, if ever, used.)
qnaal 12y ago
The idea seems be[1] that 'pressing super hard' should be easily distinguishable from 'pressing a normal amount'- which is understandable, but I don't know how preferable to announcing that pressure simply isn't supported... [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20109 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20109

thomasfoster96 12y ago

In general, browser vendors all have a history of doing things that stifle standards progress. Pointer Events (which is a good idea) has been stifled, as have lots of other relatively good or promising ideas, such as Web SQL, WebCL, etc. I'm sure browser developers have legitimate concerns about these emerging standards, but I doubt any of these concerns have warranted dumping these ideas.

bonn1 12y ago

It's true and obvious that Apple slowed down innovating the web since the core of their business is iOS and apps. They should not have an interest in a fast innovating web that gets on par with native apps which is their main lock-in for iOS, just like Microsoft did 15 years ago. They only speed up their rendering engine and JS core but don't try to help on standards improving the web experience. BUT: I doubt this pointer event thing is a good example for their strategy because it's really just a nice-to-have feature for the Surface and the Note series which is for my taste a too small target to justify a standard. A good example for Apple reluctance to innovate the web is CSS Flexbox. CSS Flexbox is the best positioning standard I encountered, every vendor supports it, only Apple still prefixes it with -webkit. Another example is their reluctance to make WKWebview fully workable, since months there is still a bug which prevents WKWebview loading local files, the bug was already fixed in an early beta of iOS 8 but then they put it again in. WKWebKit is way more performant than UIWebview and can produce butter smooth HTML5 apps with Cordova/Phonegap but this one bug makes it hard (people already build local web servers to work around this problem).

deleted 12y ago
[deleted]