Apple stifling the work of web standard
timkadlec.com
timkadlec.com
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
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/ (disclaimer: I helped write this one :) )
Irrelevant. Did they give a promise not to do so? If not, using that API would be commercial suicide.
The problem is, as it always is, that since the details aren't specified the implementations turn out incompatible. A concrete example: Should the touchmove event trigger the mousemove event? I believe it does in IE and Firefox, while it does not in Chrome and Safari. It isn't specified anywhere, and can make it incredibly complex to implement something that works with both mouse and touch input. And it is exactly the type of thing that Pointer Events sets out to fix.
This is also exactly the same story as with the <meta name="viewport"> tag. Apple did something, and the others made not-fully compatible copies. No exaggeration: Right now the only(!) thing that works consistently cross platform is setting width=device-width. It is insane, and it hurts the web.
Pointer events are a better spec, Touch events are like Mouse events, a narrow definition of the possible interactions with a device.Each time there is a new medium, are we going to write a new spec? no ,that's what pointer events are about.It's a better spec. Apple thinks touch events are good enough right now and choose not to give a fuck, well, if other vendors choose to act like Apple,there is no consensus anymore. If Microsoft did the same right now, they'd be insulted out of existence by developers, but when it's Apple,hey free pass.
Except for on mobile Apple are a minor player, and even on mobile Google is still the major player.
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.
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-...
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?
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
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.
"Not Invented Here": https://en.wikipedia.org/wiki/Not_Invented_Here
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-ch...
Device share is irrelevant considering the context is w3c/browswer standards. The relevance of money is to explain Apple's behavior, not condone it. The richest candidate does rather overwhelmingly tend to win, I'm not saying it's right, I'm saying I understand it. If you want to change such outcomes it takes a lot of work.
The relevance of NIH/RDF is they're fighting a culture that probably can't be fought. It'd be better to work on Google and possibly even Microsoft of all companies to get the momentum they need for this standard. All of the same arguments lobbed against Microsoft before and during the significant work of the w3c for either being an anchor or torpedo are the same here. It's simply how big companies behave, and I know a bunch of Apple fans who suggested Apple would never do this if they ever "won" and ended up on top, because they're somehow good/ethical and Microsoft was malicious. And now we see just how neutral the morality of big companies really is because Apple doesn't have to act maliciously to stop progress.
All Apple has to do is have a walled garden with the best API's only available to native apps, and then sit on their laurels with the web browser. It's different only in the details of what Microsoft did. I personally don't like this, but history repeating itself is hardly surprising.
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-...
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.
If you write a standard, and no one uses it, what use is it exactly? If Apple were to come up with a competing standard, in a year, which "standard" would you believe will have more use?
Apple has better control of mobile developer mindshare (almost a monopoly) and if Apple isn't onboard with your "standard" it may be very difficult to get it adopted among developers. Even worse if Apple were to decide to do things differently, their marketshare can make that the defacto standard, which Google will happily follow suit in order to appease developers and wasting everyone else's time that bothered to implement pointer events.
> The CPU analogy doesn't work either,
Its not a perfect analogy, but my point is developers don't target platforms solely based on marketshare. There are a lot more x86 toolchain developers than your all your favorite ubiquitous 8 bit microcontrollers.
Only non-people don't use Apple, got it.
> 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.
Are majority of these phones capable of running a browser that'd adopt support for Pointer Events or Touch Events? Yes, then they're counted, no?
> 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].
I still don't understand what it has to do with web standards that everyone will be using in the browsers? Are you telling me that because Apple users bought more apps, they should have more influence on technical standards for mobile browsers that has nothing to do with the apps they bought?
> When Apple holds the most important card - revenue - its not hard to see that they are in the best position for stifling standards.
Seems like a bad idea to allow them to keep doing this. We didn't get the best outcome letting MS pull this crap back in 90s. But then again, history tend to repeat itself.
They aren't. Microsoft submitted PointerEvents forever ago. But I'm assuming naivety is leading you to believe that standards mean much. Everyone could today agree make PointerEvents a standard. Now Android, WinMo, Opera and Firefox support PointerEvents. Now what? You still have a large number of developers targeting iOS not using the standard. You can shame Apple, but Apple always gets a free pass. Worse still, lets say Apple comes out with "iEvents". Now every developer is now using "iEvents" in web, despite PointerEvents exists. Of course Google wants Android browsers to be performant with whatever is popular, so they adopt "iEvents" as well. Now everyone is using "iEvents" even though PointerEvents is the standard. All because Apple controls a lot of developer mindshare.
Remember, everyone doing "bleeding edge" mobile work is pretty much targeting iOS first - so "hyped" technologies are usually supported by Apple's platform.
This is less about tech companies "willing to allow a single company to slow things down" and more about the fact a single company, because of its dominance, can and will slow things down.
>Seems like a bad idea to allow them to keep doing this. We didn't get the best outcome letting MS pull this crap back in 90s. But then again, history tend to repeat itself.
It IS a bad idea. Its the same position MS had in the 90s. Thats what we should be saying here and not deluding ourself into thinking that Apple's position matters less because Google has more market share.
Have you not heard of free software? Free software, by definition, can't contribute to mobile [software] revenue.
Its like saying "8-bit CPUs are 90% of the CPU market, so I don't get why anyone cares about Intel".
This is hugely disingenuous, because general desktop computing isn't serviced by 8-bit CPUs. They're very different use-cases. Unlike [smart]phones.
Basically what you're saying is that Bugatti matters more than Toyota in the automobile market, but only if you count the niche that Bugatti sells to.
When standard bodies were left to their own devices, we got XHTML.
We also got SI units. Or, if you want something more computery, we got JPEG.
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/SquidReportClie...
> 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.
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).
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.
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).