10 ms·

Safari Technology Preview Release Notes

87 points by clairity 4y ago

deleted 4y ago
[deleted]
londons_explore 4y ago
> Removed the 1ms minimum for setTimeout This one is big - it finally means there are no arbitrary delays when using setTimeout to add something to the next iteration of the javascript main event loop.
- wdb 4y ago
  Never knew this limitation existed
  - bryanrasmussen 4y ago
    only in Safari evidently, so it's really a bug fix on their part.
    - jkrems 4y ago
      Until very recently it was a thing in all browsers, with a variety of lower bounds depending on which browser. It was meant to prevent accidental busy-loops when developers forgot the set the time parameter IIRC.
      - bryanrasmussen 4y ago
        hmm, I can't recall ever noticing it but probably I didn't because it didn't come up or more likely because if I want immediate I explicitly set 0, but anyway the ticket https://trac.webkit.org/changeset/291998/webkit/ https://trac.webkit.org/changeset/291998/webkit/ says >This patch removes the 1ms minimum for setTimeout. The HTML spec makes no mention of such a minimum, and Firefox and Chrome do not enforce this minimum so I guess it was other browsers with the varying minimums, or these two removed it earlier.
- deleted 4y ago
  [deleted]
- tzs 4y ago
  A bit OT, but setTimeout this reminds me of something I've wondered about. Suppose you want to make some DOM change, and then when that change has actually been rendered so that the user can see it you want to do something else. How do you actually wait for a DOM change to show up? I first ran into this many years ago when I wanted clicking on a table column header to change the sorting of the table with the sort happening client side. The table was big enough that it could take a few seconds to sort, and this was before JavaScript had any true asynchronous computing mechanisms so the page would be unresponsive during the sort. I wanted to change some text near the table to "Sorting...please wait", do the sort, then clear the text. A Stack Overflow answer said to use setTimeout of 0, and do the sort in the callback. In the pseudocode below, indentation means something done in the callback of the last function above with less indentation and the callback parameter will be omitted in the function that sets the callback. So that Stack Overflow answer said do this. set_wait_message() setTimeout(0) sort_table_and_clear_wait_message() It said that browsers all special cased 0 timeout and took it to mean run when the browser finishes all current pending processing, which included all DOM changes that JavaScript had made but that have not yet rendered. I tested it on all the major browsers back then, on Windows, Linux, and Mac, and it indeed worked. Great. But then a few years later I needed it again...and this time it did not work. Timeout 0 callbacks in Firefox were now always running the sort before the DOM updated. I tried double timeout 0: set_wait_message() setTimeout(0) setTimeout(0) sort_table_and_clear_wait_message() That sometimes did the trick but sometimes did not. Stack Overflow and some Googling suggested that the idea should still be sound, but rather than setTimeout one should use window.requestAnimationFrame (rAF) or window.requestIdleCallback (rIC). On Firefox, those gave similar results to the double timeout 0. On Chrome, where single timeout 0 still worked, rIC worked the same as timeout 0, but rAF seemed to always run the callback code before the DOM update. On Safari timeout 0 and rAF worked, and Safari at the time did not have rIC. On Edge, both timeout 0 and rAF seemed to work, and edge did not have rIC. I then tested double rAF and double rIC. Both of those seemed reliable on Firefox and Chrome. And since Safari, and Edge all have rAF, and even single rAF seems to work there, double rAF works on them too. So, as of about 4 years ago when I last looked into this this seems the way to update the DOM, wait for the update to be visible, and then do something: make_DOM_changes() window.requestAnimationFrame() window.requestAnimationFrame() // DOM changes are visible But is this actually guaranteed? Or just an accident of current implementations? PS: here's a test page to play with this: https://pastebin.com/n26iVs7d https://pastebin.com/n26iVs7d The various buttons in the bottom section increment the count shown at the top then do a slow task. If it takes a second for the count to update then the slow task was not deferred until after the DOM update.
- ash_gti 4y ago
  There is queueMicrotask (https://developer.mozilla.org/en-US/docs/Web/API/queueMicrotask https://developer.mozilla.org/en-US/docs/Web/API/queueMicrot...) to queue onto the end of the current iteration and you can use an `await 0;` to cycle the event loop as well.
ramesh31 4y ago
Excited to finally have a parent selector, but this feels like a major footgun that will promote brittle DOM specific CSS.
- WalterGR 4y ago
  :has() sounds amazing on the surface. I’d be interested in a good advantages / disadvantages overview if anyone :has() a link. Edit: Useful: https://caniuse.com/?search=has https://caniuse.com/?search=has
  - clairity 4y ago
    there are a bunch of good articles out there on :has() now, like this one: https://www.smashingmagazine.com/2021/06/has-native-css-parent-selector/ https://www.smashingmagazine.com/2021/06/has-native-css-pare... i've been experimenting with it on safari tech preview, and it really lets you do many things that were previously impossible or unacceptably brittle. i love it. same with container queries. have been experimenting, it's really nice compared to page grids and breakpoint hell.
    - nicoburns 4y ago
      Ohhh, I didn't know that container queries are finally being implemented. I'd given up on them as something that would be great but didn't look like they were going to happen.
  - arrakeen 4y ago
    it's extremely useful for defining ublock origin rules
    - WalterGR 4y ago
      So far I've only used it in TamperMonkey. Between your comment and culturestate's[0], you may be on to something. [0] https://news.ycombinator.com/item?id=31369223 https://news.ycombinator.com/item?id=31369223
cyral 4y ago
For anyone curious, there are a ton of selectors here that you may have never heard of before here: https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-classes https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-clas...
- clairity 4y ago
  while many of those other pseudo-classes are useful, :has() is a next level of usefulness, as are :is()/:where() and :not(). combining these together gives you far-reaching selector capabilities. safari also now has lch colors and the color() function, which make theming more flexible. and the color-contrast() function just landed in firefox beta! edit: subgrid in firefox is pretty nifty too.
  - Klathmon 4y ago
    I don't think I've ever been excited for a CSS feature as much as I am for `:has` and `:where`!
    - CharlesW 4y ago
      For anyone else who's never heard of these before: https://developer.mozilla.org/en-US/docs/Web/CSS/:has https://developer.mozilla.org/en-US/docs/Web/CSS/:has https://developer.mozilla.org/en-US/docs/Web/CSS/:where https://developer.mozilla.org/en-US/docs/Web/CSS/:where
simonw 4y ago
I wish there was a convention to favor paragraphs over sentences in release notes. Understanding most of these release notes requires an extremely deep understanding of WebKit and the relevant web standards. I'd love to see projects invest more effort in expanding these out. Imagine how much more valuable this document would be if each of the bullet points (or just the most important bullet points) had a couple more sentences clarifying what it meant. (This is one of the reasons I've started trying to publish annotated versions of the release notes for my own projects: https://simonwillison.net/tags/annotatedreleasenotes/ https://simonwillison.net/tags/annotatedreleasenotes/ )
- deleted 4y ago
  [deleted]
- WalterGR 4y ago
  > https://simonwillison.net/tags/annotatedreleasenotes/ https://simonwillison.net/tags/annotatedreleasenotes/ Those are amazing. Well done.
- jyrkesh 4y ago
  I completely agree, but as someone who's owned publishing for changelogs on large-ish, often super technical OSS projects, it can be very difficult to explain some of the concepts needed to grok a bugfix or low-level design change even in the span of a couple paragraphs. And more importantly, that context needs to be written by the engineer involved in the change, which means more context == less code work. That being said, I think some projects do it extremely well. My gold standard for a while has actually been the OSS Dolphin emulator for Gamecube/Wii. They write incredible progress reports[1] every 1-2 months that give phenomenal context on how they found the bug, why it matters, how it works, and what they did to fix it. Another great example is VS Code[2]. Their context tends to be around changes that are more UX-oriented, but it's still a great way to understand what new value you're getting on every new release. [1]: https://dolphin-emu.org/blog/2022/02/08/dolphin-progress-report-nov-and-dec-2021-jan-2022/ https://dolphin-emu.org/blog/2022/02/08/dolphin-progress-rep... [2]: https://code.visualstudio.com/updates/v1_67 https://code.visualstudio.com/updates/v1_67
SquareWheel 4y ago
I didn't realize Safari already had support for cascade layers. I'm really excited for the reduction in specificity that will allow once frameworks and themes get on board.
- clairity 4y ago
  i've been using :where() to reduce specificity in recent projects. it's not quite the same as cascade layers, but provides a lot of benefit now for modern browsers (support goes back about 2 years).
andrethegiant 4y ago
I wish outline could respect border-radius like in other browsers.
- realusername 4y ago
  Don't know if they fixed the buggy border-radius on videos either.
- lucsky 4y ago
  This has been a known bug for 14 (FOURTEEN) years (https://bugs.webkit.org/show_bug.cgi?id=20807 https://bugs.webkit.org/show_bug.cgi?id=20807). I have lost hope at this point.
scottlamb 4y ago
I see mention of Media Source Extensions (MSE) in these release notes. Good to see they're improving it, I guess. But my understanding [1] is that while Safari on Desktop and iPad support MSE, Safari on iPhone does not. Does anyone know why this restriction exists and if it's likely to be removed? I'd expect these to be substantially the same codebase so the restriction confuses me. I saw folks speculating about business reasons for this restriction, which confuses me. It seems like HLS provides broadly similar functionality, so I'm not sure how many determined folks are entirely stopped from doing something by Apple's technology choice, or steered toward a native app, or whatever Apple supposedly wants instead. This just makes things unnecessarily painful for small projects. [1] backed up by https://caniuse.com/mediasource https://caniuse.com/mediasource
- jsmith45 4y ago
  I'd put down a lot of money on this being an artificial limitation, and not a technical issue. If I had to guess, it is that they have hyper-optimized the pipeline for HLS for battery consumption. Streaming video is one of the most power hungry things people do with their phone that laymen often don't think is power hungry. (Unlike say 3d games, or GPS). If the MSE path is less optimized (and it is, simply by nature of having JavaScript in the loop handling the video segments), which drains the battery faster, but sites like Twitch, Youtube, and Facebook switch to using MSE, then now the iPhone battery life numbers look worse.
  - scottlamb 4y ago
    Fair point; I can see them making the choice for that reason. But I'm not sure it's actually true that HLS is more optimal: * On the one hand, the MSE path makes all the data flow through Javascript. At least that means chunks must be garbage-collected. I can see it meaning an extra copy or two also. * On the other hand, doesn't HLS require polling and extra round trips? You fetch the .m3u8 manifest repeatedly, and then fetch the media segments it indicates. If you want lowest possible latency, well, it's 1.5 trips higher than necessary, as well as requiring extra network requests (costing battery for wake-ups and a bit of bandwidth/radio time). As compared to a WebSocket where the server pushes segments as soon as they're available. In an application of mine, I've thought about writing web worker code to basically create a HLS API for my service from the real, WebSocket-based API. Then it'd work on iPhone. Of course, this means everything would flow through Javascript, totally defeating what advantage HLS has and requiring (device-internal, fortunately) polling.
tiffanyh 4y ago
I can only hope Apple actually ships these Preview additions to main Safari; since they seem to have a habit of of not doing so. https://mobile.twitter.com/Dieulot/status/1473247987790921728?cxt=HHwWgICypajPg_IoAAAA https://mobile.twitter.com/Dieulot/status/147324798779092172...
darren 4y ago
Looks like there's some good performance gains here as well. Safari has traditionally been faster on the benchmarks, but recently Chrome has overtaken it. This Preview puts Safari in the lead again. Speedometer 2.0 (https://browserbench.org/Speedometer2.0/ https://browserbench.org/Speedometer2.0/) on my M1 Air: Safari 15.4: 258 runs/min Chrome 101.0.4951.64: 264 runs/min Safari Tech Preview 15.4 (release 145): 307 runs/min

87 points by clairity 4y ago

deleted 4y ago

[deleted]

> Removed the 1ms minimum for setTimeout This one is big - it finally means there are no arbitrary delays when using setTimeout to add something to the next iteration of the javascript main event loop.

wdb 4y ago
Never knew this limitation existed
- bryanrasmussen 4y ago
  only in Safari evidently, so it's really a bug fix on their part.
  - jkrems 4y ago
    Until very recently it was a thing in all browsers, with a variety of lower bounds depending on which browser. It was meant to prevent accidental busy-loops when developers forgot the set the time parameter IIRC.
    - bryanrasmussen 4y ago
      hmm, I can't recall ever noticing it but probably I didn't because it didn't come up or more likely because if I want immediate I explicitly set 0, but anyway the ticket https://trac.webkit.org/changeset/291998/webkit/ https://trac.webkit.org/changeset/291998/webkit/ says >This patch removes the 1ms minimum for setTimeout. The HTML spec makes no mention of such a minimum, and Firefox and Chrome do not enforce this minimum so I guess it was other browsers with the varying minimums, or these two removed it earlier.
deleted 4y ago
[deleted]
tzs 4y ago
A bit OT, but setTimeout this reminds me of something I've wondered about. Suppose you want to make some DOM change, and then when that change has actually been rendered so that the user can see it you want to do something else. How do you actually wait for a DOM change to show up? I first ran into this many years ago when I wanted clicking on a table column header to change the sorting of the table with the sort happening client side. The table was big enough that it could take a few seconds to sort, and this was before JavaScript had any true asynchronous computing mechanisms so the page would be unresponsive during the sort. I wanted to change some text near the table to "Sorting...please wait", do the sort, then clear the text. A Stack Overflow answer said to use setTimeout of 0, and do the sort in the callback. In the pseudocode below, indentation means something done in the callback of the last function above with less indentation and the callback parameter will be omitted in the function that sets the callback. So that Stack Overflow answer said do this. set_wait_message() setTimeout(0) sort_table_and_clear_wait_message() It said that browsers all special cased 0 timeout and took it to mean run when the browser finishes all current pending processing, which included all DOM changes that JavaScript had made but that have not yet rendered. I tested it on all the major browsers back then, on Windows, Linux, and Mac, and it indeed worked. Great. But then a few years later I needed it again...and this time it did not work. Timeout 0 callbacks in Firefox were now always running the sort before the DOM updated. I tried double timeout 0: set_wait_message() setTimeout(0) setTimeout(0) sort_table_and_clear_wait_message() That sometimes did the trick but sometimes did not. Stack Overflow and some Googling suggested that the idea should still be sound, but rather than setTimeout one should use window.requestAnimationFrame (rAF) or window.requestIdleCallback (rIC). On Firefox, those gave similar results to the double timeout 0. On Chrome, where single timeout 0 still worked, rIC worked the same as timeout 0, but rAF seemed to always run the callback code before the DOM update. On Safari timeout 0 and rAF worked, and Safari at the time did not have rIC. On Edge, both timeout 0 and rAF seemed to work, and edge did not have rIC. I then tested double rAF and double rIC. Both of those seemed reliable on Firefox and Chrome. And since Safari, and Edge all have rAF, and even single rAF seems to work there, double rAF works on them too. So, as of about 4 years ago when I last looked into this this seems the way to update the DOM, wait for the update to be visible, and then do something: make_DOM_changes() window.requestAnimationFrame() window.requestAnimationFrame() // DOM changes are visible But is this actually guaranteed? Or just an accident of current implementations? PS: here's a test page to play with this: https://pastebin.com/n26iVs7d https://pastebin.com/n26iVs7d The various buttons in the bottom section increment the count shown at the top then do a slow task. If it takes a second for the count to update then the slow task was not deferred until after the DOM update.
ash_gti 4y ago
There is queueMicrotask (https://developer.mozilla.org/en-US/docs/Web/API/queueMicrotask https://developer.mozilla.org/en-US/docs/Web/API/queueMicrot...) to queue onto the end of the current iteration and you can use an `await 0;` to cycle the event loop as well.

ramesh31 4y ago

Excited to finally have a parent selector, but this feels like a major footgun that will promote brittle DOM specific CSS.

WalterGR 4y ago
:has() sounds amazing on the surface. I’d be interested in a good advantages / disadvantages overview if anyone :has() a link. Edit: Useful: https://caniuse.com/?search=has https://caniuse.com/?search=has
- clairity 4y ago
  there are a bunch of good articles out there on :has() now, like this one: https://www.smashingmagazine.com/2021/06/has-native-css-parent-selector/ https://www.smashingmagazine.com/2021/06/has-native-css-pare... i've been experimenting with it on safari tech preview, and it really lets you do many things that were previously impossible or unacceptably brittle. i love it. same with container queries. have been experimenting, it's really nice compared to page grids and breakpoint hell.
  - nicoburns 4y ago
    Ohhh, I didn't know that container queries are finally being implemented. I'd given up on them as something that would be great but didn't look like they were going to happen.
- arrakeen 4y ago
  it's extremely useful for defining ublock origin rules
  - WalterGR 4y ago
    So far I've only used it in TamperMonkey. Between your comment and culturestate's[0], you may be on to something. [0] https://news.ycombinator.com/item?id=31369223 https://news.ycombinator.com/item?id=31369223

cyral 4y ago

For anyone curious, there are a ton of selectors here that you may have never heard of before here: https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-classes https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-clas...

clairity 4y ago
while many of those other pseudo-classes are useful, :has() is a next level of usefulness, as are :is()/:where() and :not(). combining these together gives you far-reaching selector capabilities. safari also now has lch colors and the color() function, which make theming more flexible. and the color-contrast() function just landed in firefox beta! edit: subgrid in firefox is pretty nifty too.
- Klathmon 4y ago
  I don't think I've ever been excited for a CSS feature as much as I am for `:has` and `:where`!
  - CharlesW 4y ago
    For anyone else who's never heard of these before: https://developer.mozilla.org/en-US/docs/Web/CSS/:has https://developer.mozilla.org/en-US/docs/Web/CSS/:has https://developer.mozilla.org/en-US/docs/Web/CSS/:where https://developer.mozilla.org/en-US/docs/Web/CSS/:where

simonw 4y ago

I wish there was a convention to favor paragraphs over sentences in release notes. Understanding most of these release notes requires an extremely deep understanding of WebKit and the relevant web standards. I'd love to see projects invest more effort in expanding these out. Imagine how much more valuable this document would be if each of the bullet points (or just the most important bullet points) had a couple more sentences clarifying what it meant. (This is one of the reasons I've started trying to publish annotated versions of the release notes for my own projects: https://simonwillison.net/tags/annotatedreleasenotes/ https://simonwillison.net/tags/annotatedreleasenotes/ )

deleted 4y ago
[deleted]
WalterGR 4y ago
> https://simonwillison.net/tags/annotatedreleasenotes/ https://simonwillison.net/tags/annotatedreleasenotes/ Those are amazing. Well done.
jyrkesh 4y ago
I completely agree, but as someone who's owned publishing for changelogs on large-ish, often super technical OSS projects, it can be very difficult to explain some of the concepts needed to grok a bugfix or low-level design change even in the span of a couple paragraphs. And more importantly, that context needs to be written by the engineer involved in the change, which means more context == less code work. That being said, I think some projects do it extremely well. My gold standard for a while has actually been the OSS Dolphin emulator for Gamecube/Wii. They write incredible progress reports[1] every 1-2 months that give phenomenal context on how they found the bug, why it matters, how it works, and what they did to fix it. Another great example is VS Code[2]. Their context tends to be around changes that are more UX-oriented, but it's still a great way to understand what new value you're getting on every new release. [1]: https://dolphin-emu.org/blog/2022/02/08/dolphin-progress-report-nov-and-dec-2021-jan-2022/ https://dolphin-emu.org/blog/2022/02/08/dolphin-progress-rep... [2]: https://code.visualstudio.com/updates/v1_67 https://code.visualstudio.com/updates/v1_67

SquareWheel 4y ago

I didn't realize Safari already had support for cascade layers. I'm really excited for the reduction in specificity that will allow once frameworks and themes get on board.

clairity 4y ago
i've been using :where() to reduce specificity in recent projects. it's not quite the same as cascade layers, but provides a lot of benefit now for modern browsers (support goes back about 2 years).

andrethegiant 4y ago

I wish outline could respect border-radius like in other browsers.

realusername 4y ago
Don't know if they fixed the buggy border-radius on videos either.
lucsky 4y ago
This has been a known bug for 14 (FOURTEEN) years (https://bugs.webkit.org/show_bug.cgi?id=20807 https://bugs.webkit.org/show_bug.cgi?id=20807). I have lost hope at this point.

scottlamb 4y ago

I see mention of Media Source Extensions (MSE) in these release notes. Good to see they're improving it, I guess. But my understanding [1] is that while Safari on Desktop and iPad support MSE, Safari on iPhone does not. Does anyone know why this restriction exists and if it's likely to be removed? I'd expect these to be substantially the same codebase so the restriction confuses me. I saw folks speculating about business reasons for this restriction, which confuses me. It seems like HLS provides broadly similar functionality, so I'm not sure how many determined folks are entirely stopped from doing something by Apple's technology choice, or steered toward a native app, or whatever Apple supposedly wants instead. This just makes things unnecessarily painful for small projects. [1] backed up by https://caniuse.com/mediasource https://caniuse.com/mediasource

jsmith45 4y ago
I'd put down a lot of money on this being an artificial limitation, and not a technical issue. If I had to guess, it is that they have hyper-optimized the pipeline for HLS for battery consumption. Streaming video is one of the most power hungry things people do with their phone that laymen often don't think is power hungry. (Unlike say 3d games, or GPS). If the MSE path is less optimized (and it is, simply by nature of having JavaScript in the loop handling the video segments), which drains the battery faster, but sites like Twitch, Youtube, and Facebook switch to using MSE, then now the iPhone battery life numbers look worse.
- scottlamb 4y ago
  Fair point; I can see them making the choice for that reason. But I'm not sure it's actually true that HLS is more optimal: * On the one hand, the MSE path makes all the data flow through Javascript. At least that means chunks must be garbage-collected. I can see it meaning an extra copy or two also. * On the other hand, doesn't HLS require polling and extra round trips? You fetch the .m3u8 manifest repeatedly, and then fetch the media segments it indicates. If you want lowest possible latency, well, it's 1.5 trips higher than necessary, as well as requiring extra network requests (costing battery for wake-ups and a bit of bandwidth/radio time). As compared to a WebSocket where the server pushes segments as soon as they're available. In an application of mine, I've thought about writing web worker code to basically create a HLS API for my service from the real, WebSocket-based API. Then it'd work on iPhone. Of course, this means everything would flow through Javascript, totally defeating what advantage HLS has and requiring (device-internal, fortunately) polling.

tiffanyh 4y ago

I can only hope Apple actually ships these Preview additions to main Safari; since they seem to have a habit of of not doing so. https://mobile.twitter.com/Dieulot/status/1473247987790921728?cxt=HHwWgICypajPg_IoAAAA https://mobile.twitter.com/Dieulot/status/147324798779092172...

darren 4y ago

Looks like there's some good performance gains here as well. Safari has traditionally been faster on the benchmarks, but recently Chrome has overtaken it. This Preview puts Safari in the lead again. Speedometer 2.0 (https://browserbench.org/Speedometer2.0/ https://browserbench.org/Speedometer2.0/) on my M1 Air: Safari 15.4: 258 runs/min Chrome 101.0.4951.64: 264 runs/min Safari Tech Preview 15.4 (release 145): 307 runs/min