Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blink won’t implement pointer events

code.google.com

Post reply on HN
Print view View original

41–50 of 65 posts

Re: Blink won’t implement pointer events

#41

Post by derefr »

chc wrote: post #37
panzi wrote: post #32

Earlier quoted context omitted.

Given that IE 10+ supports web sockets I don't really see the need for server sent events. What can you do with server sent events that you cannot do with web sockets? I guess one could deprecate SSE in favor of WS.

It's not what you can do, but what you have to do. Websockets are to Server-Sent Events as jet planes are to wheelbarrows. Yes, the stuff jet planes can carry is a superset of the stuff wheelbarrows can carry, but the cost is greater and it ends up being a suboptimal in many cases where you'd want to use a wheelbarrow.

Also, most people who think they want the semantics of websockets, really want the semantics of SSE. I've seen many, many webapps that basically build SSE on top of websockets.

Re: Blink won’t implement pointer events

#42

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

Re: Blink won’t implement pointer events

#43

Post by rbyers »

matthewmacleod wrote: post #3

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…

> I'm pretty sure Microsoft is going to go full steam ahead with pointer events.

Note that even Microsoft acknowledges the "touch events are here to stay" argument: IE mobile now supports touch events: http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web...

Re: Blink won’t implement pointer events

#44

Post by stonogo »

rbyers wrote: post #28
zghst wrote: post #23

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…

Well said. We're deeply committed on the blink team to making such polyfills and frameworks easy (eg. it's a big part of why we shipped touch-action in blink). That's where the fighting over what API shape is "best" can best happen - in a market with unlimited choice and furious competition.

You must be operating with AT&T's definition of 'unlimited,' which experimentation has shown to be around three.

Re: Blink won’t implement pointer events

#45

Post by earp »

cobalt wrote: post #40
oatmealsnap wrote: post #35

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

https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-eve...

That's the CSS property already being used. The controversial specification is at https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEve...

Re: Blink won’t implement pointer events

#46

Post by jvilk »

underwater wrote: post #15

"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…

> I wish we could move towards a model where browser vendors would expose low level APIs...

You might find this academic paper from James Mickens interesting, which explores this exact idea in detail:

http://sigops.org/sosp/sosp11/current/2011-Cascais/printable...

Re: Blink won’t implement pointer events

#47

Post by Encosia »

zghst wrote: post #23

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…

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.

Re: Blink won’t implement pointer events

#48

Post by jgillich »

Encosia wrote: post #47
zghst wrote: post #23

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…

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 imp…

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.

Re: Blink won’t implement pointer events

#49

Post by panzi »

stephenr wrote: post #38
panzi wrote: post #32

Earlier quoted context omitted.

Given that IE 10+ supports web sockets I don't really see the need for server sent events. What can you do with server sent events that you cannot do with web sockets? I guess one could deprecate SSE in favor of WS.

SSE is trivial to support via a polyfill, and has none of the connectivity issues websockets has, so it's capable across a much wider array of devices/software both client side and server/network side I feel that websockets is like the xml of this decade - "everyone is using it" so everyone wants to use it.

How can you polyfill it? Long polling JSON?

Re: Blink won’t implement pointer events

#50

Post by malandrew »

underwater wrote: post #15

"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…

What we want/need is basically this: 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.

Post reply on HN