New WebKit Features in Safari 15.5 | Hacker News Reader

New WebKit Features in Safari 15.5

webkit.org

66 pointsfeross87 comments

While we're making wishlists for Safari, the one I think would have the most real world impact is AV1 support, to have a modern royalty-free codec across all browsers if Safari adds it. Safari is the last holdout. Considering the large proportion of internet usage is to transfer video, the savings in storage and transmission would be non-trivial.

Apple is very close with the media entities that receive royalties from MPEG, h.264, etc, so I wouldn't hold your breath.

Until there are enough devices with an av1 hardware decoder, any storage and transmission saving is lost to the higher energy usage and worse battery life for the end user.

My phone already has av1 hardware decoding (pixel 6). But anyway it's a chicken/egg problem, where the broader hardware decoding will come once browser support is there. The long-term impacts are more significant.

Also, energy use worldwide might decline if fewer datacenters are needed to store/transmit videos. Kind of hard to measure and compare against enduser devices, but it's another factor to consider.

Apple makes both its browser and its hardware, so it's not really a chicken/egg problem for them. But they are a member of Alliance for Open Media, so maybe this WWDC or next they will announce something.

>Also, energy use worldwide might decline if fewer datacenters are needed to store/transmit videos.

You dont save on Storage, you are storing an additional copy of video using a different codec.

webkit leads the dance for once, with their amazing h265 support

I do not expect this to happen until Apple starts including a hardware decoder in their silicon.

I could have sworn this landed some time ago, so I looked it up. Turns out I was partly right. Partial WebKit support was added in 2020[1], but it depends on which decoder is available. According to metadata on the commit, it looks like this shipped in Safari 15.4. No telling if/when they’ll add hardware support, but they’ve been more receptive to royalty free codecs in recent years then their historical reputation suggests.

1: https://github.com/WebKit/WebKit/commit/db84a4ca534c01144461...

Safari media support requires OS update, not the browser or engine.

Still waiting for Apple to enable PREFETCH

https://caniuse.com/link-rel-prefetch

It's been there since Safari v13.1 but disabled by default.

(PreFetch is what allows https://instant.page to load assets super fast.)

And also extensively used for privacy invasive tracking (1) there is no same-origin restriction for link prefetching and (2) it allow cookies to be planted from tracking servers. ( https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe... ).

I thought CSP mitigate this risk.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

As you can see in the linked page, no browser supports it.

Gotta say, really disappointed with the fact that instead of Safari making 100vh actually mean 100% of viewport height like it's supposed to, they instead present us with all these new viewport units, all to fix a problem that was caused by their own deviation from the spec to begin with. And of course they're not going to do anything about 100vh even with all these new units, because how else are we going to force developers to use our special units to cater to our browser's quirks!

What spec? I just looked up what the issue is with vh on mobile and the very first resource I found talked about how the spec isn't clear on how it's supposed to behave in the presence of movable chrome, like the address bar on mobile browsers.

It also says that Safari's initial implementation updated `vh` when the address bar changed visibility and this caused a bad jump in layout, which is why they changed it to ignore the address bar so it's a fixed value instead. And it says Chrome mobile followed suite as well, which means it's not just Safari that thinks the "fixed value" approach is better on mobile.

I've yet to meet a single developer who likes what Apple did with 100vh. And it's why all my projects to date that want to use viewport height in CSS have ended up adding a JS snippet that sets a --vh CSS variable to window.innerHeight on resize, because I have no interest in dealing with Apple's special boy CSS behavior. And really, even Apple itself admits that their 100vh solution is troublesome - they wouldn't have introduced all these new units otherwise! Even if the saner solution would have been to just change their idiosyncratic 100vh behavior to what developers actually expect from it.

And what do "developers" expect from it? Because as a user I certainly remember that it used to be very common for website layout to jump around in an aggravating fashion when hiding the address bar.

These new units do not indicate that Apple's 100vh behavior is "troublesome", they indicate that mobile needs better viewport units than desktop does. Which is why there are three separate new viewport units, to correspond to the three different desired measurements. Even if Apple never changed 100vh behavior, these new set of units are a significant improvement.

100vh is a good default for unaware websites, because otherwise you get unexpected layout jump. The other units are good tools for aware developers who intentionally want to match largest, smallest, or dynamic height. Seems like best of both worlds.

Still waiting for MSE and fullscreen API support in iOS Safari for better media support without having to roll out an app. Both have been available on iPadOS for a few years now.

I keep hoping for the bluetooth api to be added at some point. Still unlikely unfortunately :-(

0 chance of that happening

yeah, apple is pretty stubborn on that one. I’m glad we have Chrome

The nice thing about Chrome is that any and every feature is implemented.

The bad thing about Chrome is that any and every feature is implemented.

There's still some things Safari prioritizes that other vendors don't have. For example, Chrome (and FF) still haven't fully implemented CSS colors level 4.

Chrome and Firefox are still clamping all CSS colors to sRGB. You literally can't render anything outside of sRGB with CSS. And almost all modern Apple devices are capable of the display-p3 color space.

This is very noticeable when rendering reds and greens, especially.

https://webkit.org/blog/10042/wide-gamut-color-in-css-with-d...

this is not true anymore, chromium added support for other color spaces this year

Chrome supports CSS level 4 color functions, but they're clamped to sRGB. AKA, basically useless.

https://bugs.chromium.org/p/chromium/issues/detail?id=106861...

Edit: Actually, I don't think Chrome even supports CSS level 4 color functions. (It sounds like it's part of interop2022 though!)

Do you know when the clamping will be removed? I was referring to this https://chromestatus.com/feature/4592567062626304

Have I hallucinated? I wzs sure support for it was added recently

Edit according to the last comment in the issue you linked, this is on the 2022 roadmap, it's about time to properly support HDR!

Both Safari and Firefox are stubborn on that one (and most other hardware APIs), and for good reasons.

They can code working security models for other features so fingerprinting isn't a good reason.

Firefox is actually looking at WebMidi now so they've clearly had a change of heart. Apple will never do it because it means you can make hardware devices that interact with iPhones without going through the App Store.

> They can code working security models for other features so fingerprinting isn't a good reason.

And those working security models are?

> Firefox is actually looking at WebMidi now so they've clearly had a change of heart.

They didn't have a "change of heart". They most likely found a way to implement it the way it aligns with their position.

Pop up a dialog asking for permission to scan for devices.

That's not a working security model when it's required for about a dozen such permissions (camera, mike, location, bluetooth, serial ports, midi, ambient light, gyroscopes, hid, ...)

Chrome doesn't care and pushes these out.

Safari and Mozilla: protections in these specs are inadequate for the large surface area and complexity that these APIs require

That’s a week cop out from Apple when they offer far less protection in Native and allow apps to use Bluetooth to monitor your location.

Web Bluetooth has much BETTER security and privacy than native. By not providing functionality it forces apps to use the AppStore.

> That’s a week cop out from Apple

Too bad Mozilla also thinks the same way.

> By not providing functionality it forces apps to use the AppStore.

Nice conspiracy theory. I wonder if Mozilla execs are in on it.

Mozilla seems to have come around with WebMIDI, so thats a good step in the right direction. The functionality is not limited to device APIs, it covers every aspect of the browser.

See: https://open-web-advocacy.org/walled-gardens-report/#hobbled...

and

https://open-web-advocacy.org/walled-gardens-report/#missing...

> Mozilla seems to have come around with WebMIDI

And yet, we are in a thread about WebBluetooth.

Both Safari and Mozilla have the same stance: until a proper solution for privacy issues with hardware specs is found, we oppose them.

For WebMIDI it seems Mozilla has found a solution they are happy with. I wouldn't hold mu breath for others.

The links you provided assume Mozilla is in on Apple conspiracy, too. It's also a very one-sided take which completely ignores the elephant in the room. See this: https://www.quirksmode.org/blog/archives/2021/08/breaking_th...

Web Bluetooth is significantly safer than native bluetooth + the safest car is the one that doesn't start is not a good direction for the web.

FYI only native signs a blank cheque and lets you scan for devices in the background. Web Bluetooth requires the browser itself to connect to a device and specify a service for you to connect too.

They might be forced to if the EU makes them to open up to other browser engines. I can see that happening

Seems like that is set to become a reality thankfully https://www.theregister.com/2022/04/26/apple_ios_browser/

Frankly, I think it’s either the worlds biggest coincidence or the only reason we are seeing any effort from Apple to start playing long overdue catch-up on the web now is because regulators started sniffing around.

It’s not a coincidence, Apple just didn’t have any motivation to invest in Safari until the threat of competition came along.

The increased investment is great for Safari and the web, now we just need some core functionality to support mobile web apps and I think we could really see it take off.

If the rest of the market were healthy, I'd be happy about this, but it's really, really not healthy. Apple's the only entity keeping Google from dictating web standards for everyone, and mobile Safari, specifically, is the only reason they have enough leverage to be able to do that. This will trade a monopoly on one tiny slice of the market (web browser engines—not web browsers, just the engine—on iOS devices) for Google having the whole pie.

Yeah, I am forever thankful that my browser isn’t vending my Bluetooth devices to random websites. I don’t understand why so many people want so much of their machine state to be vended to random websites.

That's not how it would work. You would need to grant permission to websites and there are good use cases. No website could just randomly scan.

Scanning is native only. Web Bluetooth does not slow scanning and you have to specify specific device categories or services to connect too without being able to work out what devices are there first.

Read the security section on the Web Bluetooth spec.

I have been using Firefox & macOS for about the last 4-5 years. I primarily use it because I enjoy the bookmark sync between my Mac and linux desktops and because I try using open-source software as much as reasonably possible. However I will used a closed-source product when I feel it is better than the open source option. (E.g. MS Excel) It seems like Safari has been rapidly improving as of late. Any recommendations to try it again over Firefox? Would be a bit annoying to find some sort of "bookmark sync" solution again, but something good probably exists out there.

The main selling point is that it's far more respectful of system resources than its big two competitors. Noticeably lower power use, reduced effects on performance of other software outside the browser.

If the rest of your stuff is also Apple, browser sync is a pretty solid Just Works thing, which can be a benefit of using it, but you're not all-Apple, so that benefit's out.

[EDIT] "So what are the downsides?" worse dev tools, worse add-on ecosystem. Sometimes it's missing engine features that FF and Chrome have (this never hinders me at all in practice, with my usage patterns, and in fact I'm usually glad when they choose not to uncritically and promptly implement every single feature Google adds to Chrome, but I understand it bothers some people a lot, so would definitely count against Safari if those features are things you really want/need)

This is exactly why I use safari, it's not perfect, but it respects the battery life to a noticeable extent.

I love it. In my eyes it’s the best browser because of that and it’s Apple ecosystem integration.

It also feels so much faster. Maybe the others have caught up on the Mac over the years. But it used to be night and day.

I even use it for development. The dev tools are fine for me. I agree FF/Chrome are better, so I use them when I need it. Especially for the React or Redux plug-ins.

But for standard JS errors and CSS tinkering I find Safari works just fine.

I didn't know that it was lighter on system resources, that's interesting. Makes me wonder if a FF-based Electron would ever take off, because the main issue with Electron apps is the insane amount of memory consumption (last I checked anyways). Especially if you have multiple electron apps running simultaneously.

> I didn't know that it was lighter on system resources, that's interesting. Makes me wonder if a FF-based Electron would ever take off, because the main issue with Electron apps is the insane amount of memory consumption

During my own Great Browser Migration, part of my motivation for going from FF to Chrome was that Chrome caused fewer beachballs when I wasn't even using it (I'm a tab hoarder, so it's my own damn fault, kinda). My switch to Safari came when I realized it almost never caused a beachball (plus the huge battery life improvement).

I'd hope Chrome and FF have both gotten better (this was about ten years ago), but I still use FF off-and-on (though mostly on Windows) and my sense is that it hasn't improved a ton on that front. My understanding is you can fix much of this with various add-ons, though, at least on Firefox (less sure about Chrome). The Great Suspender, stuff like that. I've not used them, though.

AFAIK Firefox has The great suspender built in.

> and in fact I'm usually glad when they choose not to uncritically and promptly implement every single feature Google adds to Chrome, but I understand it bothers some people a lot, so would definitely count against Safari if those features are things you really want/need)

Thanks someone for bring it up. More features Chrome add are in the larger scheme of thing invates our privacy, WebTorrent (leaks IP addresses of the other peers). WebGPU leaks hardware info finger printing, etc.

By using web browser I expect some sort of sandboxing. Why do I need all these features in a document based viewing portal?

I moved from Firefox to Safari solely because I can two-finger pinch into a grid view of open tabs - and also it has a 'share' button that integrates with my Mac and allows me to dump websites as PDFs to my knowledge repo (DEVONthink), I was never able to organize bookmarks in a way that I looked at them ever again.

There's a pretty slick tab grouping interface but I always forget its there.

Another cool Safari tab UI feature, if you use the bottom URL bar, is you can swipe between tabs without even viewing the tab grid view at all. And if you’re at the end of the tab list, another swipe will create a new tab.

The swipe feature also makes more obvious, but easier to work around, bugs in the open in new tab -> back button feature (which is also awesome, when it works).

o thanks never heard of that

it's taking all of my willpower to learn to use two-finger-swipe back instead of my lifelong muscle "right click" "back"

whats the new tab -> back button feature?

> whats the new tab -> back button feature?

By default if you open a new tab from a link (either intentionally or by clicking a link which opens one for you), Safari adds the linking page to your history for that new tab. If you click back, it’ll close the tab and take you back to your previous state in the tab you left. It works really well when it works, but often leaves zombie tabs open with unclear history if you navigate around in the new tab.

It seems like Apple is accelerating WebKit/Safari changes.

They have accelerated and started hiring massively around October last year, that is when several regulators started investigating the browser engine ban on iOS (the CMA in the UK first).

Correct - after years of deliberately hobbling Safari so you couldn't build quality app experiences, they suddenly start releasing lots of useful improvement just as regulators are sniffing around.

I keep seeing this conspiracy. It came out during the epic trial that the vast majority of revenue from the App Store comes from pay to win games. Apple isn’t making money off of apps that could be a web apps.

The vast majority of apps you see on the App Store, including most games can be web apps. So I'm not sure what your point is?

Apple has deliberately under-invested in implementing web platform features on Safari. If you've tried to build a web app on Safari vs Android Chrome, you'll know what I mean. It's not a conspiracy - it's a clear as day policy to keep consumers and developers locked into their platform.

How many pay to win games are web apps on Android then?

Why didn’t Epic just make all of their game web apps on Android and PC.

That’s really just more evidence to support the theory and is in no way exculpatory.

The only thing it adds to the picture is that the majority of their revenue is also extremely predatory and the underlying model essentially works the same way as slot machines.

It’s an awful business model. It’s one thing to have Safari hobbled because of high quality business apps and games, another for loot boxes, gems and countdown timers to exploit whales.

If only Safari is hobbled to not allow games - why are all popular games native apps on Android?

The main advantage of the web is interoperability, if you don’t have that and the game engines developers just go for native.

Once the core gaming APIs are supported across both iOS and Android (WebGPU, SIMD, WASM threads, fast storage, install prompts, notifications), I think you will see the main gaming engines implemented and then you’ll see the games move.

The game studios like in app purchasing where you get to buy loot boxes and other zero marginal cost goods without thinking about it.

We have a control in the experiment - we have an “open ecosystem” in Android and supposedly a much better browser - yet and still, game developers still choose to give Google the same 30% cut as Apple. Maybe it’s not because Apple is holding the web back?

I think it's one of those things, that if you're not using Safari to develop Web Apps it's very hard to see what the problems are from the outside.

If you get some time we've written a lot of detail about it here: https://open-web-advocacy.org/walled-gardens-report/

Personally I hate loot boxes etc, It's an awful business model.

I’m not claiming or not claiming that Safari is best at supporting “web standards”. I’m simply saying that if Apple supported every web standard in the world, the revenue generating apps would still be native.

Quiet, or you'll logic everyone out of their sincerely held conspiracy theories.

What should they do? Ban pay for win games? They already offer Apple Arcade that doesn’t have any of the predatory practices. They can’t be making that much charging $4.95 and paying game developers an advance.

any links? (on the hirings)

https://jobs.apple.com/en-us/search?search=WebKit&sort=relev...

Those are open jobs which is great to see. Is there a way to see the existing number of employees working on webkit?

it was an abandonware until last year

They’ve consistently added features with every OS release cycle.

Which isn’t nearly as fast as other browsers move, but it was never abandonware.

Haven’t checked yet but assume that canvas memory management is probably still broken.

`inert` sounds like something that could be abused, similar to how websites (annoyingly) try to block you from easily right-click saving photos.

`inert` doesn't let you do anything you couldn't do before, it just does it with one attribute instead of a half-dozen attributes and CSS rules that need to be applied to the element and its children.

You can defeat right-click save-as about ten different ways already so that ship has sailed. And all of those can be defeated using the Application tab in the Chrome dev tools or mitmproxy etc.

It’s desperately needed to implement current patterns like model dialogs in an accessible way. It doesn’t do anything JavaScript can’t already do so I don’t think it’s any worse for abuse.

Safari is like internet explorer and where I spend the majority of my day fixing issues related to quirks and bugs

> Fixed scrolling background-attachment: fixed

oh, joy! only took 8+ years:

https://stackoverflow.com/questions/23236158/how-to-replicat...

I am still insanely upset that there are a lot of years spanning bugs which aren't fixed in Safari or even acknowledged in their bug tracker, but the situation is getting a lot better with the release frequency and new features so at least there is hope for things to get better from here.

I understand the feeling, we’d stopped bothering to lodge tickets until this year. If you find ones that haven’t got attention and they’re still important, tweet at webkit or Jen. They’ve been really good with bugs recently and they are getting fixed.

If you do find new bugs I would encourage you to make tickets.

when will they support sharedworkers..

Reply on news.ycombinator.com