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

21–30 of 65 posts

Re: Blink won’t implement pointer events

#21

Post by randomfool »

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…

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.

Re: Blink won’t implement pointer events

#22

Post by robin_reala »

underwater wrote: post #18

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

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.

Re: Blink won’t implement pointer events

#23

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

Re: Blink won’t implement pointer events

#24

Post by jaffathecake »

robin_reala wrote: post #22
underwater wrote: post #18

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

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.

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

Re: Blink won’t implement pointer events

#25

Post by d7Bw9bPZ »

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…

Correct me if I'm wrong, but wouldn't Google themselves be one of those vendors as well? Android has cursor support, and there are a few ChromeOS laptops that ship with touchscreens as well. Although, not owning any of them, I'll readily admit that I'm not sure if/how the browser distinguishes between those events - the OS might be abstracting all of that away too.

Re: Blink won’t implement pointer events

#26

Post by zghst »

fidotron wrote: post #4

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

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.

Re: Blink won’t implement pointer events

#27

Post by mcav »

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…

(although server-sent-events are supported by just about everything except IE: http://caniuse.com/eventsource )

Re: Blink won’t implement pointer events

#28

Post by rbyers »

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.

Re: Blink won’t implement pointer events

#29

Post by rbyers »

aikah wrote: post #7
matthewmacleod wrote: post #5

Earlier quoted context omitted.

Touch events for instance are a still proprietary API. It's a W3C recommendation http://www.w3.org/TR/touch-events/

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

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.

Re: Blink won’t implement pointer events

#30

Post by rbyers »

d7Bw9bPZ wrote: post #25
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…

Correct me if I'm wrong, but wouldn't Google themselves be one of those vendors as well? Android has cursor support, and there are a few ChromeOS laptops that ship with touchscreens as well. Although, not owning any of them, I'll readily admit that I'm not sure if/how the browser distinguishes between those events - the OS might be abstracting all of that away too.

Right, we (Chrome team) definitely care about multi-input-device scenarios (I started at Google by leading the chrome work for the chromebook pixel). We're just trying to project out 5-10 years where we expect most Interent traffic to come from phones/tablets to a mobile-first (touch-first) world - rather than carry the baggage of the mouse-centric world. Here's some ramblings on how we may be able to evolve touch events to fill this need: http://crbug.com/404128
Post reply on HN