

Apple stifling the work of web standard - sberder
http://timkadlec.com/2015/02/apples-web/

======
camhenlin
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 :) )

~~~
aikah
The article isn't about polyfills, and polyfills don't make up for specs
everybody agrees on. You say you disagree with the article,but nothing in your
message is related in anyway with the article.

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.

~~~
camhenlin
I'd like to point out that Microsoft did the exact same thing with pointer
events with IE10-11 up until the very latest version of Windows 8.1 which is
still not rolled out to all devices on all networks

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

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

~~~
nemothekid
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-...](http://www.techspot.com/news/58456-google-play-vs-app-store-
downloads.html)

~~~
mikhailt
I am probably extremely naive here but I just don't understand why technical
companies are willing to allow one single company to slow things down just
because they seem to have the most "revenue" that shouldn't matter for
technical standards.

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

~~~
nemothekid
> _I am probably extremely naive here but I just don 't understand why
> technical companies are willing to allow one single company to slow things
> down just because they seem to have the most "revenue" that shouldn't matter
> for technical standards._

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.

------
franciscop
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
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.)

------
bonn1
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).

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

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

~~~
ygra
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).

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

~~~
mikhailt
Microsoft is adopting support for Touch
Events:[https://status.modern.ie/touchevents?term=touch](https://status.modern.ie/touchevents?term=touch)

~~~
camhenlin
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.

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

