4 ms·

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

by zghst 12y ago

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)

mcav 12y ago
(although server-sent-events are supported by just about everything except IE: http://caniuse.com/eventsource http://caniuse.com/eventsource )
- panzi 12y ago
  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.
  - chc 12y ago
    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.
    - derefr 12y ago
      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.
  - stephenr 12y ago
    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.
    - panzi 12y ago
      How can you polyfill it? Long polling JSON?
      - stephenr 12y ago
        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
rbyers 12y ago
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.
- stonogo 12y ago
  You must be operating with AT&T's definition of 'unlimited,' which experimentation has shown to be around three.
panzi 12y ago
Shame, I would really like to have cross browser support for CSS Masking and Clipping. Masking stuff with a gradient in particular.
deleted 12y ago
[deleted]
Encosia 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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.

by zghst 12y ago

mcav 12y ago

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

panzi 12y ago
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.
- chc 12y ago
  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.
  - derefr 12y ago
    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.
- stephenr 12y ago
  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.
  - panzi 12y ago
    How can you polyfill it? Long polling JSON?
    - stephenr 12y ago
      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

rbyers 12y ago

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.

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

panzi 12y ago

Shame, I would really like to have cross browser support for CSS Masking and Clipping. Masking stuff with a gradient in particular.

deleted 12y ago

[deleted]

Encosia 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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.