Safari Technology Preview Release Notes

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.

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.

Not sure if that could theoretically be related to MSE being missing, but maybe it’s in a similar vein of control.

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

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

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

PS: here's a test page to play with this: 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.

Edit: Useful: https://caniuse.com/?search=has

I can’t say I’ve really considered this in any depth, but my very first thought when I saw :has() was “finally, I can fix those last stupid bugs in my HN userstyle.”

So…you may be on to something.

Those are amazing. Well done.

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

[2]: https://code.visualstudio.com/updates/v1_67