

Blink won’t implement pointer events - robin_reala
https://code.google.com/p/chromium/issues/detail?id=162757#c64

======
zghst
Seeing that Google doesn't want to add anything to its browser that is not
essential and will not penalize performance, this was obviously not going to
make the cut.

Pointer events would be nice, but using a polyfill isn't so bad. Even if they
implemented pointer events, we would still have to implement a polyfill for
backwards and cross platform compatibility.

For those of who complain of standards, look at the CSS Regions standard. It's
dead and the only browser that has a strong implementation of it is Safari.
Other examples of non implemented or partially implemented standards by the
browsers: SVG animations, Server sent events, CSP, CSS filters, CSS Images
Values and Replaced Content (i.e. cross-fade() images), Intrinsic Sizing,
Media Capture and Streams, CSS Masking and Clipping, Web Speech API, CSS Clip
paths, User Timing API, the list is endless.

Not to mention that IE and Firefox seem to be very slow at implementing any
CSS styling related properties like CSS filters, masking, shapes, 3D CSS
transforms (Firefox struggled for a bit and now IE is 'struggling' to
implement them fully)

~~~
Encosia
Recent versions of IE have been very noticeably faster on my machines than
Chrome. Every time I open IE up to test a site that I've been working on in
Chrome, it's amazing how much smoother animations are and how much quicker
pages render. Ironically, this difference between them is most readily
apparent when using touch to scroll and zoom.

I'm all for making performance a priority, but the IE team found a way to
implement pointer events without sacrificing performance. Surely they aren't
uniquely capable of this engineering feat.

In the long run, shackling the web to the iPhone 1's touch input scheme seems
awfully short sighted. I don't know if IE's pointer event model is the best
alternative, but touchstart/down/up/stop definitely isn't.

~~~
jgillich
IE is faster in some areas because it uses some very controversial tricks,
like caching all AJAX requests for the entire session. So yeah, it might be
faster, but you might also get outdated data.

~~~
Encosia
When I think about how IE is faster on my machines, I'm mainly thinking in
terms of page rendering performance after the first byte and
animation/scrolling smoothness.

Lately, I've actually found myself lamenting that I needed to further optimize
a couple sites so they'd run smoothly on Chrome and/or Safari, when they were
already buttery smooth in IE. That's something I never thought I'd find myself
thinking.

(BTW, I see that someone downvoted you, but that wasn't me. Your point about
AJAX caching is a good one.)

~~~
nostrademons
I've heard that IE9+ has very effective GPU rendering. That could explain its
rendering and animation/scrolling performance. The GPU compositor in Chrome &
Safari is kinda hacked-in; it renders layers on the CPU first, blits them to
the GPU as a texture, and then composits on a full-layer basis. Touch the CPU
renderer and performance immediately goes to shit.

I wouldn't be surprised if things get better, at least for Chrome, in the near
future.

------
underwater
"Touch events are here to stay".

Ugh, that's such a defeatist attitude. And it seems unfounded. Most developers
use some form of abstraction on top of native events, such as jQuery or React.

I wish we could move towards a model where browser vendors would expose low
level APIs and let libraries implement simple interfaces on top of them. At
the moment we end up having to write browser-specific hacks that "guess" the
state of the world based on weird heuristics and browser sniffing:
[https://github.com/facebook/react/blob/master/src/browser/ev...](https://github.com/facebook/react/blob/master/src/browser/eventPlugins/BeforeInputEventPlugin.js#L125)

~~~
malandrew
What we want/need is basically this:
[http://extensiblewebmanifesto.org/](http://extensiblewebmanifesto.org/)

The problem for Google is that an extensible web is a threat t their business
model based around search. This is why they are so adamant about force pushing
web components and polyfills. It's the least offensive (and least compute
intensive) approach to their web crawler.

It's much easier and cheaper for them (as a business) to get everyone to adopt
a half-baked and half-thought out standard that allows their crawler to
extract content from a page without having to execute javascript to understand
what is there.

With the right APIs, a JavaScript rich web can still be an accessible web for
the physically impaired. OS X is proof that this possible. However, this
approach makes it far far more expensive for web crawlers at scale since it's
not as simple as just parsing a document. Forcing everything into a cheaply
parseable document is just Google externalizing their costs on the rest of
society.

Every decision made for blink needs two be viewed with two lenses: (1) what
does this change mean for the Chrome web browser?; and (2) what does this
change mean for the Google web crawler? At the end of the day, those two are
closely related.

~~~
comex
You realize that that website explicitly promotes polyfills ("enable feature
development and iteration in JavaScript")? Also, "explain existing features"
is theoretically one of the goals for Web Components.

More pertinent to this issue, one of the Googler posts in the relevant public-
pointer-events discussion cites that site:

[http://lists.w3.org/Archives/Public/public-pointer-
events/20...](http://lists.w3.org/Archives/Public/public-pointer-
events/2014JulSep/0054.html)

~~~
malandrew
Yes, I absolutely understand that. I'm talking about one level lower than what
web components will enable. I talking about the notion of how we got to the
current details regarding web components (I'm hesitant to use the term "spec"
since it lends more officialness than there actually is. The entire foundation
and architecture of web components has been rushed and there have been
attempts to foist that specific feature upon the web without adequate time for
others to question its design and direction.

There is a huge difference between the polyfill that is Polymer and the W3C
Web Components specification.

The former is a polyfill that developers can only rely on if they explicitly
include it as a dependency in their project. The latter is a feature that is
(or at least should be) baked into the current version of every modern web
browser out there.

The former conveys an architectural design decision that you must consciously
make and that there may be other legitimate alternatives (known and unknown)
that you may want to consider instead of the one you're familiar with. The
latter conveys that there is one true way of accomplishing task/need X and to
stray from using that standardized feature is only for either heretics or the
brave.

The former creates a scenario that promotes a proliferation of alternatives.
The latter squanders the intellectual capacity of the community with respect
to a specific problem that is "officially solved".

To declare a "problem officially solved" with an inadequate solution is
professional malpractice, IMHO.

The issue I'm talking about here was the fiasco earlier this year where the
Chrome team announced the intent to ship web component features _without the
use of a developer flag_ despite the fact that the feature that was not
defined in a w3c spec draft much less a mature spec[0]. When you have the
market share that Chrome has, shipping without requiring a developer flag is
tantamount to saying "Standards schmandards! We're gonna do whatever we want
like we're building Internet Explorer in the late 90s!"

[0] [http://lists.w3.org/Archives/Public/www-
style/2014Feb/0103.h...](http://lists.w3.org/Archives/Public/www-
style/2014Feb/0103.html)

~~~
walterbell
Within the web standards community, is there a cluster of companies/interests
supporting the position being advocated above, who are not encumbered by a
Google business relationship?

~~~
malandrew
Besides us and the individual developers out there like unconed (Steven
Wittens)[0] that truly understand the problem here, I honestly don't know.

I know that the Safari devs are unencumbered and disagree with the Google
approach, but I don't know what position they do support as an alternative. I
just know that their position does not coincide with Google's position.

TBH, there isn't a whole lot of diversity among those working in this space.
There are a lot of developers working on graphics, rendering and layout. There
are a lot of developers working on web standards. The intersection of those
two groups if plotted as a Venn diagram, is pretty small. After all we really
only have a few user agents out there: webkit (safari), blink (chrome), gecko
(firefox), servo (?) and trident (internet explorer).

The web would benefit immensely from having many more of the devs in the
former group involved. I personally would love to hear ideas and get
contributions from developers that work on projects/technologies like qt and
wpf.

[0] [http://acko.net/blog/shadow-dom/](http://acko.net/blog/shadow-dom/)

------
matthewmacleod
This is interesting, because I'm pretty sure Microsoft is going to go full
steam ahead with pointer events. Indeed, they're the only major vendor of a
device that supports both mouse and touch (finger AND stylus) events – it's
going to be super important to handle those events well.

I'm not totally convinced by the Blink argument – the fact that "touch events
are here to stay" is irrelevant, given the unifying nature of pointer events;
"fast by default" is a noble goal, but must be a trade-off with functionality;
and the whole event-handling-scrolling mess doesn't seem like enough of a deal
breaker to preclude tweaks to the spec to fix it.

That said, I'm sure they've had extensive discussions about it and made this
decision for a good reason - I hope they now push ahead hard with an
alternative solution to these problems.

~~~
dmethvin
The unifying nature of pointer events is what makes them so important for the
future. Otherwise you have to implement multiple pointer models on a device
that provides more than one, or try to simulate one from the other which
becomes a mess of lies that the app developer has to sort through.

I've already worked with a couple of companies that have been bitten by
assuming a device has either touch or mouse, but not both. They had code to
the effect of `if ( touchstart in document ) { attach touch events } else {
attach mouse events }` but then they ran into Chrome on a Windows 8 system
with a touch screen. Whoops. Now their site only works if you touch the
screen.

If you think this is "only a problem on those crazy Windows 8 notebooks" then
you're not thinking ahead to systems that will use a Kinect, eye tracking, or
some other advanced technique to implement pointers. Devs are really going to
hate it when those interesting input methods are sliced and diced into mouse
or touch (or God forbid BOTH) in order to shove it into Apple's 2007 vision of
a web page input world.

~~~
randomfool
There is already the need to support alternate input mechanisms in the form of
accessibility and keyboard navigation.

Creating UI widgets that work well everywhere is a non-trivial task that is
frequently underestimated.

What this really highlights is the need for high quality UI toolkits which
abstracts these details. If a developer is complaining about supporting mouse
and touch, then they're most likely missing out on many more details and
should be using some pre-built components instead.

------
underwater
I hadn't heard of the performance implications of pointer events before. In my
experience Internet Explorer is actually really incredible when it comes to
touch performance.

If you have a touch-enabled Windows device, open up t.msn.com and try swiping
through the carousel. It's powered by -ms-scroll-snap-points and feels really
good - even on mobile devices. It beats hand-rolled JavaScript scrolling
implementations hands down.

As a developer, being able to add `pointer-events: none` to CSS is amazing
when compared to adding and removing touch event listeners in iOS to avoid
blocking the so the scroll thread.

~~~
robin_reala
For what it’s worth pointer-events:none; is a completely different thing: it’s
cribbed from SVG and has nothing to do with MS’s spec.

~~~
jaffathecake
Yep, -ms-scroll-snap-points is also a different thing.

------
oatmealsnap
Can someone explain what these pointer events are? I assume this is different
from the CSS property already being used...

~~~
cobalt
[https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-
eve...](https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-events)

~~~
earp
That's the CSS property already being used. The controversial specification is
at [https://dvcs.w3.org/hg/pointerevents/raw-
file/tip/pointerEve...](https://dvcs.w3.org/hg/pointerevents/raw-
file/tip/pointerEvents.html)

------
aikah
If it becomes a standard I guess they will reconsider their choice.

We are in a weird era where HTML5/web apis kind of succeeded ,making plugins
almost obsolete, yet i'm still not sure 5/10 years from now,vendors will still
be on that same line.The temptation of implementing proprietary APIs is still
huge.

Touch events for instance are a still proprietary API.

~~~
matthewmacleod
_Touch events for instance are a still proprietary API._

It's a W3C recommendation [http://www.w3.org/TR/touch-
events/](http://www.w3.org/TR/touch-events/)

~~~
aikah
AFAIK there was a issue with Apple holding some copyrights on the api,might
have changed.

~~~
rbyers
There was a delay, but we worked past it. The web would definitely be a better
place if Apple would participate in the input API standardization process
though.

------
realusername
One thing which makes me sad is the lack of structure of the Javascript API.
Everything is now built using Javascript and the JS VM is not following any
UNIX principles in its implementation. I would really like to have a UNIX-like
JS API.

A small example: let's say that you want to redirect the error output to the
standard output.

Since everything is a file descriptor on UNIX, you can just call dup2(2) and
this won't have any repercussion on other parts of the program. You can also
redirect any error to a file just by using this on a file descriptor you got
from open (2).

But in Javascript, everything is different, you have to redeclare
console.error and hope that this won't break anything if some library is doing
exactly the same thing as you somewhere. This is also the same problem with
XMLHttpRequest and various javascript APIs. (including the File and Blob API
to read files on the browser).

~~~
reubenmorais
>Since everything is a file descriptor on UNIX, you can just call dup2(2) and
this won't have any repercussion on other parts of the program.

You chose an unfortunate example. From the dup2 documentation:

    
    
         The object referenced by the descriptor does not distinguish between fildes and fildes2 in any way.
         Thus if fildes2 and fildes are duplicate references to an open file, read(2), write(2) and lseek(2)
         calls all move a single pointer into the file, and append mode, non-blocking I/O and asynchronous I/O
         options are shared between the references.  If a separate pointer into the file is desired, a different
         object reference to the file must be obtained by issuing an additional open(2) call.  The close-on-exec
         flag on the new file descriptor is unset.

~~~
evmar
And on top of that, you have to worry about CLOEXEC if your process can fork,
so you need to consider using dup3.

------
earp
I wonder what will happen with the Polymer polyfills for WebComponents, a
technology that Safari also hasn't declared intent to implement. And then I
wonder what will happen with the polyfill for PointerEvents that _already_
comes bundled with Polymer, which by the way works great in Safari. But most
of all, I wonder what this all means for Polymer PointerGestures, which is
exactly what we need around here:
[https://github.com/Polymer/PointerGestures](https://github.com/Polymer/PointerGestures).
I'm starting to think that this may all go the way of all those technologies
with an X in it's acronmym, which are largely forgotten today because of
similar reasoning from Google's lobbyists. You have to assume that the future
of these things is longer than the past. That's why you should never put
politicians in charge of it.

~~~
dfreedm2
I actually replaced PointerEvents use in Polymer with
[https://github.com/polymer/polymer-
gestures/](https://github.com/polymer/polymer-gestures/) a couple of months
ago: [https://groups.google.com/forum/#!topic/polymer-
dev/ba4aDyOo...](https://groups.google.com/forum/#!topic/polymer-
dev/ba4aDyOozm8)

~~~
earp
Good info. With no specification to back it up, I might go back to my hand-
rolled gestures-style library. I retired it because of imminent
standardization, but at this point, it seems as likely to be standardized as
everything else. I promise to take PolymerGestures for a spin, though, since I
was happy with the coding going into those libs now deprecated. Thanks!

------
fidotron
People used to complain about mobile device fragmentation, but the web is now
looking more fragmented than at any point since IE3 vs Netscape, and whoever
else decided to chuck together an excuse for a browser and release it.

The approach where all the vendors are ignoring each other as much as possible
while pursuing their own improvements has created a giant mess. What is
strangling the situation is there is no consistent vision of what they're
actually trying to achieve, so the resulting platform is incoherent, and thus
absolutely joyless to work with.

~~~
zghst
Pointer events aren't too big of a deal, they are simple polyfills for them.
Collaboration between the vendors today has never been better.

Just look at IE, it went from being a last place browser to being a second
class browser (first class being Firefox and Chrome). IE 10 pioneered CSS
grids, the basis for a mature CSS flexbox spec (thank you MS!!!!), CSS regions
(although it is only iFrames =/), setImmediate, pointer events. The
competition and collaborations between the browsers (and Adobe) today has set
an era for stability and phenomenal progress.

Just thinking about the next IE version gets me tingling: __partial ES6 __,
__Media capture __, HTTP2, Web Audio API, etc. I could have never imagined
that the IE team would become so sharp! Now if they can implement some CSS
stuff as well (masking, shapes, composting, blending and filters PRETTY
PLEASE) and make the browser more deferential to the content (shrink title
bars and remove the border around the window por favor), then I will fall in
love as I have with Safari.

~~~
rbyers
Agreed! We had a great "input face-to-face" meeting at Microsoft back in June,
and the collaboration between IE, Safari, Firefox and Chrome teams seems
better than ever. Despite our differences of opinion, we finally all appear to
be working towards common goals with interoperability foremost.

------
based2
[http://www.reddit.com/r/programming/comments/2dq1bl/google_t...](http://www.reddit.com/r/programming/comments/2dq1bl/google_to_drop_microsoftdesigned_touch_web_spec/)

