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

51–60 of 65 posts

Re: Blink won’t implement pointer events

#51

Post by dfreedm2 »

earp wrote: post #42

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://git…

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

Re: Blink won’t implement pointer events

#52

Post by Encosia »

jgillich wrote: post #48
Encosia wrote: post #47

Earlier quoted context omitted.

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.

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

Re: Blink won’t implement pointer events

#53

Post by nostrademons »

Encosia wrote: post #52
jgillich wrote: post #48

Earlier quoted context omitted.

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.

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

Re: Blink won’t implement pointer events

#54

Post by stephenr »

panzi wrote: post #49
stephenr wrote: post #38

Earlier quoted context omitted.

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?

There are several polyfills linked from modernizer and I haven't looked at them all but I would imagine so yes. Because it tracks the last-read message ID, a broken connection is not a deal breaker

Re: Blink won’t implement pointer events

#55

Post by comex »

malandrew wrote: post #50
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 ad…

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

Re: Blink won’t implement pointer events

#56

Post by malandrew »

comex wrote: post #55
malandrew wrote: post #50

Earlier quoted context omitted.

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

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

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

Re: Blink won’t implement pointer events

#57

Post by walterbell »

malandrew wrote: post #56
comex wrote: post #55

Earlier quoted context omitted.

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

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

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?

Re: Blink won’t implement pointer events

#58

Post by cbr »

dmethvin wrote: post #14
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…

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

> If you think this is "only a problem on those crazy Windows 8 notebooks"...

Many Chromebooks also have touchscreens.

Re: Blink won’t implement pointer events

#59

Post by cromwellian »

fidotron wrote: post #13
andybak wrote: post #10

Earlier quoted context omitted.

I think you've reached a slightly perverse conclusion. From the source: >Pointer events would likely never supplant touch events on the web (especially without support from Safari). Since touch events are here to stay, supporting another largely redundant input model has a high long-term complexity cost on the web platform. Sounds to me like the Blink time is trying to use their say to reduce fragmentation and they'v…

The Blink team have simply become the new IE style refuseniks, using mobile performance as the standard excuse. Mozilla, Apple and Microsoft have all been creating new "standard" APIs which no one else implements, yet in order to get best performance on their systems you have to use. If you read the history of that bug someone rightly points out a key thing is MS have to support the pen on surface, and that was as im…

You mean like Apple refusing Pointer Events first, or Mozilla refusing WebP, NaCL/PNaCl/Pepper, trying to refuse Web Audio, MS refusing WebGL, Canvas, Web Audio, WebRTC.

Every vendor fights their own turf battles. Not-invented-here seems to also be a big issue in standards committees.

Post reply on HN