3 ms·

You seem to have missed the part of my comment that said "since IE6" AFAIK the box-sizing box model you mentioned was implemented since the beginning of Triden

You seem to have missed the part of my comment that said "since IE6" AFAIK the box-sizing box model you mentioned was implemented since the beginning of Trident, well before IE6 came about. XHR was available from IE5 onwards (only accessible via ActiveX object, it didn't become available as a native window property in JS until IE7 but the feature was still available), so again isn't "since IE6". If you think whether it was available in native JS matters, note that Mozilla had a native JS XHR object available in 2002, well before it was available in IE7 in 2006. I specifically mentioned "since IE6" because that was the point at which Microsoft had decided they'd won the browser war, and ceased to innovate. From that point onwards they have been playing a perpetual game of catch-up, constantly lagging behind other browsers in implementing new specifications and features. setImmediate is not standardised for good reason, there are already more appropriate use-case specific solutions: use `requestAnimationFrame` if you are working with animations/visual changes use `postMessage` or WebWorkers if you are working with transporting or processing heavy data There's no browser use-case enabled by `setImmediate` that isn't supported by one of the above. It does however make sense for `setImmediate` to be implemented in node because a node environment lacks the two APIs mentioned above and doesn't really have any way of achieving the desired outcome short of forking child processes.

exogen 8y ago
I see you have never had to implement Promises in userland. :) setImmediate is one of the more popular polyfills in fact, all the workarounds you mentioned either have downsides or are ugly hacks. It's useful to anything that has a scheduler. Like Vue for example. Maybe someone should tell Evan You that it doesn't make sense to need setImmediate? https://github.com/vuejs/vue/blob/b111de486b1bdc747fe0f5795fe22697d151bb8c/src/core/util/next-tick.js#L33-L35 https://github.com/vuejs/vue/blob/b111de486b1bdc747fe0f5795f... Check the download counts: https://www.npmjs.com/package/setimmediate https://www.npmjs.com/package/setimmediate https://www.npmjs.com/package/next-tick https://www.npmjs.com/package/next-tick https://www.npmjs.com/package/set-immediate-shim https://www.npmjs.com/package/set-immediate-shim https://www.npmjs.com/package/core-js#setimmediate https://www.npmjs.com/package/core-js#setimmediate
jancsika 8y ago
> You seem to have missed the part of my comment that said "since IE6" IIRC the pointer events specification[1] came from Microsoft and is implemented in Chrome and Firefox (just checked and found setPointerCapture in devTools-- yay). It allows developers to use a unified approach that can work for various pointer devices. I can confirm it does just that in Chrome and am waiting to hear back from someone who will test it with multi-touch on a surface pro. That API was released well after IE6. [1] https://www.w3.org/TR/pointerevents/ https://www.w3.org/TR/pointerevents/
gsnedders 8y ago
> From that point onwards they have been playing a perpetual game of catch-up, constantly lagging behind other browsers in implementing new specifications and features. There are definitely examples: IE8 was the first browser with separate content processes (before Chrome was announced). CSS Grid was heavily pushed by MS (and shipped, prefixed, in IE10). Ultimately, being in a game of perpetual catchup in unsurprising when they stood still, with only an absolute minimal amount of work happening, for three years, while other browsers continued to march forwards.
- WorldMaker 8y ago
  It's not just the interregnum/break that made it a game of perpetual catchup, though. Google certainly helped a lot to keep the goal posts moving. Web SQL, SPDY, QUIC, VP8, VP9, WebRTC, etc and so forth, are just some of examples of Google pushing half-finished standards into Chrome, then encouraging devs to use them (even in prefixed forms, where applicable), well in advance of standards processes. It's easy to be "standards compliant" when you are the ones building the standards and everyone else has to work to support your bugs/mistakes/half-finished backward incompatible solutions, because real world sites already rely on them. (That's exactly the IE6 problem in a nutshell.) When many of those real world sites that folks rely on are Google-owned properties themselves (looking at you, tube), there is almost no way to keep the goal posts from moving.

exogen 8y ago

I see you have never had to implement Promises in userland. :) setImmediate is one of the more popular polyfills in fact, all the workarounds you mentioned either have downsides or are ugly hacks. It's useful to anything that has a scheduler. Like Vue for example. Maybe someone should tell Evan You that it doesn't make sense to need setImmediate? https://github.com/vuejs/vue/blob/b111de486b1bdc747fe0f5795fe22697d151bb8c/src/core/util/next-tick.js#L33-L35 https://github.com/vuejs/vue/blob/b111de486b1bdc747fe0f5795f... Check the download counts: https://www.npmjs.com/package/setimmediate https://www.npmjs.com/package/setimmediate https://www.npmjs.com/package/next-tick https://www.npmjs.com/package/next-tick https://www.npmjs.com/package/set-immediate-shim https://www.npmjs.com/package/set-immediate-shim https://www.npmjs.com/package/core-js#setimmediate https://www.npmjs.com/package/core-js#setimmediate

jancsika 8y ago

> You seem to have missed the part of my comment that said "since IE6" IIRC the pointer events specification[1] came from Microsoft and is implemented in Chrome and Firefox (just checked and found setPointerCapture in devTools-- yay). It allows developers to use a unified approach that can work for various pointer devices. I can confirm it does just that in Chrome and am waiting to hear back from someone who will test it with multi-touch on a surface pro. That API was released well after IE6. [1] https://www.w3.org/TR/pointerevents/ https://www.w3.org/TR/pointerevents/

gsnedders 8y ago

> From that point onwards they have been playing a perpetual game of catch-up, constantly lagging behind other browsers in implementing new specifications and features. There are definitely examples: IE8 was the first browser with separate content processes (before Chrome was announced). CSS Grid was heavily pushed by MS (and shipped, prefixed, in IE10). Ultimately, being in a game of perpetual catchup in unsurprising when they stood still, with only an absolute minimal amount of work happening, for three years, while other browsers continued to march forwards.

WorldMaker 8y ago
It's not just the interregnum/break that made it a game of perpetual catchup, though. Google certainly helped a lot to keep the goal posts moving. Web SQL, SPDY, QUIC, VP8, VP9, WebRTC, etc and so forth, are just some of examples of Google pushing half-finished standards into Chrome, then encouraging devs to use them (even in prefixed forms, where applicable), well in advance of standards processes. It's easy to be "standards compliant" when you are the ones building the standards and everyone else has to work to support your bugs/mistakes/half-finished backward incompatible solutions, because real world sites already rely on them. (That's exactly the IE6 problem in a nutshell.) When many of those real world sites that folks rely on are Google-owned properties themselves (looking at you, tube), there is almost no way to keep the goal posts from moving.