WebKit Features in Safari 16.1(webkit.org)
webkit.org
WebKit Features in Safari 16.1
https://webkit.org/blog/13399/webkit-features-in-safari-16-1/
65 comments
Still no prefetch to help websites load faster :(
It’s a little more nuanced than that.
1. prefetch has no role regarding initial page load, which is the thing most people care about most; not supporting it has no effect on that.
2. prefetch is a browser hint; during browser idle time, using some heuristic, it downloads resources in the background it thinks you might need or pages you might navigate to next. If it guesses correctly, the next navigation is fast, because the page and its resources, (assuming they have rel=prefetch assigned to them) is already in the cache. If the browser is wrong, there’s no benefit.
3. Users who don’t have unlimited cellular data and pay by the megabyte probably don’t want the browser downloading stuff in the background they didn’t ask for and may not need.
4. There are privacy implications. From Mozilla’s Link prefetching FAQ [1]:
Privacy implications Along with the referral and URL-following implications already mentioned above, prefetching will generally cause the cookies of the prefetched site to be accessed. (For example, if you google amazon, the Google results page will prefetch www.amazon.com, causing amazon cookies to be sent back and forth. You can block 3rd party cookies in Firefox, see Disabling third party cookies.)
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe...
It’s a little more nuanced than that.
1. prefetch has no role regarding initial page load, which is the thing most people care about most; not supporting it has no effect on that.
2. prefetch is a browser hint; during browser idle time, using some heuristic, it downloads resources in the background it thinks you might need or pages you might navigate to next. If it guesses correctly, the next navigation is fast, because the page and its resources, (assuming they have rel=prefetch assigned to them) is already in the cache. If the browser is wrong, there’s no benefit.
3. Users who don’t have unlimited cellular data and pay by the megabyte probably don’t want the browser downloading stuff in the background they didn’t ask for and may not need.
4. There are privacy implications. From Mozilla’s Link prefetching FAQ [1]:
Privacy implications Along with the referral and URL-following implications already mentioned above, prefetching will generally cause the cookies of the prefetched site to be accessed. (For example, if you google amazon, the Google results page will prefetch www.amazon.com, causing amazon cookies to be sent back and forth. You can block 3rd party cookies in Firefox, see Disabling third party cookies.)
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe...
1. For web SaaS it’s a huge benefit. Because it allows you to download assets you know are needed prior to logging into your the SaaS app that would otherwise cause a huge initial load to be slow.
2. What you described sounds like a net positive since you didn’t state any negatives.
3. If the concern is mobile bandwidth cost, simple solution is for Apple to only enable this feature for desktop Safari (not iOS).
4. There is a technical solution with cookie sandboxing.
2. What you described sounds like a net positive since you didn’t state any negatives.
3. If the concern is mobile bandwidth cost, simple solution is for Apple to only enable this feature for desktop Safari (not iOS).
4. There is a technical solution with cookie sandboxing.
3. If the concern is mobile bandwidth cost, simple solution is for Apple to only enable this feature for desktop Safari (not iOS).
Short answer: no. A laptop could be using a metered mobile hotspot while an iPhone could be on a fast Wi-Fi network.
There’s away to indicate a user wants to save data [1]. This would tell the service to not do things like download resources in the background I may not need or use, which is what rel=prefetch does.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sa...
Short answer: no. A laptop could be using a metered mobile hotspot while an iPhone could be on a fast Wi-Fi network.
There’s away to indicate a user wants to save data [1]. This would tell the service to not do things like download resources in the background I may not need or use, which is what rel=prefetch does.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sa...
If your Mac is connected to metered mobile network, for example, you don't want to download software updates automatically. To support such situation, Windows supports "metered connection" settings to distinguish connection. Some apps regard the settings so it save data usage until it connect to unlimited connection. https://support.microsoft.com/en-us/windows/metered-connecti... https://www.windowslatest.com/2020/11/17/chrome-will-finally...
I have looked for something like this in macOS and can't find it. IMHO for a kernel that's also running on mobile devices not having a low data mode is inexplicable.
If the only advantage is for SaaS initial load time, then there are other solutions available for developers on a single domain (admittedly more complicated than "link rel=prefetch"). Meanwhile, the downsides and potential for abuse loom large.
Most people encounter SaaS initial load time much more rarely than they do web advertising or unscrupulous web developers, and SaaS providers have other ways of more accurately measuring traffic than means which are distorted by prefetching.
I, for one, have disabled what little pre-fetching Safari does offer, the "Preload Top Hit in Background" option under Search preferences. No thank you!
Most people encounter SaaS initial load time much more rarely than they do web advertising or unscrupulous web developers, and SaaS providers have other ways of more accurately measuring traffic than means which are distorted by prefetching.
I, for one, have disabled what little pre-fetching Safari does offer, the "Preload Top Hit in Background" option under Search preferences. No thank you!
Falsehoods Programmers Believe About Network Connections, #4827:
"Cellular/limited data" and "on a mobile device (smartphone or similar)" are equivalent.
"Cellular/limited data" and "on a mobile device (smartphone or similar)" are equivalent.
Because it allows you to download assets you know are needed prior to logging into your the SaaS app that would otherwise cause a huge initial load to be slow.
That’s what rel=preload does, not rel=prefetch. As I mentioned, prefetch runs during idle time and the browser certainly isn’t idle when doing an initial page load.
Of course Safari supports rel=preload.
That’s what rel=preload does, not rel=prefetch. As I mentioned, prefetch runs during idle time and the browser certainly isn’t idle when doing an initial page load.
Of course Safari supports rel=preload.
I might be mistaken but I was under the impression that if you PRELOAD an asset, and that asset is not actually used on the page in which preloaded it - then that asset doesn't get cached for use on a future page. However, if you PREFETCH an asset and it's not used on that page - it does in fact get cached for future use.
Is my understanding incorrect?
https://html.spec.whatwg.org/multipage/links.html#linkTypes
Is my understanding incorrect?
https://html.spec.whatwg.org/multipage/links.html#linkTypes
I might be mistaken but I was under the impression that if you PRELOAD an asset, and that asset is not actually used on the page in which preloaded it - then that asset doesn't get cached for use on a future page.
The point of using rel=preload is because you want to start downloading a resource before it’s discovered in your HTML or CSS for the current navigation. If the resource doesn’t get used on the current navigation, it stays in the cache, because you said you needed the resource.
However, preloading something then not using it is a waste of bandwidth and possibly screws up the priority of how resources load. If you preload something and you don’t use it, that bandwidth could have been used to download something you do use.
If you need something for the next navigation—say your homepage is splash page and you want a nearly instantaneous transition to the next page—that’s when you would use prefetch. When the user navigates to the next page, all of your important resources are in the cache and can be used immediately.
If your resources are on servers that aren’t your origin (like a CDN) but you don’t need them yet, you can use rel=preconnect, which does the DNS lookup and the TLS handshake in the background, so when it’s time to download from the CDN, you’re not delayed by the DNS lookup and the TLS handshake, because it’s already done.
If you need resources from several different non-origin servers, the amount of time for DNS lookups and TLS handshakes starts to add up.
The point of using rel=preload is because you want to start downloading a resource before it’s discovered in your HTML or CSS for the current navigation. If the resource doesn’t get used on the current navigation, it stays in the cache, because you said you needed the resource.
However, preloading something then not using it is a waste of bandwidth and possibly screws up the priority of how resources load. If you preload something and you don’t use it, that bandwidth could have been used to download something you do use.
If you need something for the next navigation—say your homepage is splash page and you want a nearly instantaneous transition to the next page—that’s when you would use prefetch. When the user navigates to the next page, all of your important resources are in the cache and can be used immediately.
If your resources are on servers that aren’t your origin (like a CDN) but you don’t need them yet, you can use rel=preconnect, which does the DNS lookup and the TLS handshake in the background, so when it’s time to download from the CDN, you’re not delayed by the DNS lookup and the TLS handshake, because it’s already done.
If you need resources from several different non-origin servers, the amount of time for DNS lookups and TLS handshakes starts to add up.
I keep hearing the argument that it’s a waste to prefetch assets that might not get used.
Yet, is it ok that so many web developers use bloated JS libraries that causes websites to be multiple MBs in size when it could easily only be 10s of KB?
How is that not a bigger waste?
Yet, is it ok that so many web developers use bloated JS libraries that causes websites to be multiple MBs in size when it could easily only be 10s of KB?
How is that not a bigger waste?
Yet, is it ok that so many web developers use bloated JS libraries that causes websites to be multiple MBs in size when it could easily only be 10s of KB?
How is that not a bigger waste?
You’ll get no argument from me regarding bloated JS libraries. But the reason why preload was created to make page downloads faster, not reduce asset sizes.
I keep hearing the argument that it’s a waste to prefetch assets that might not get used.
Preloading assets you don’t use can be a waste of bandwidth because that bandwidth could have been used to download something you’re going to actually use. Also, preload bumps up the priority of that resource, perhaps jumping ahead of an asset you really need.
For users with the latest devices on broadband connections, it may not make much of a difference. But when you’re cell connection is two bars and you’re on 3G instead of 5G, it matters.
You’ll get no argument from me regarding bloated JS libraries. But the reason why preload was created to make page downloads faster, not reduce asset sizes.
I keep hearing the argument that it’s a waste to prefetch assets that might not get used.
Preloading assets you don’t use can be a waste of bandwidth because that bandwidth could have been used to download something you’re going to actually use. Also, preload bumps up the priority of that resource, perhaps jumping ahead of an asset you really need.
For users with the latest devices on broadband connections, it may not make much of a difference. But when you’re cell connection is two bars and you’re on 3G instead of 5G, it matters.
1. What? If you "need" them prior to logging in, they're going to be loaded regardless, and your app will be stuck until that happens regardless. How long do you think people are sitting at login screens?
2. No, it's a statement that a correct implementation of preloading is free ignore any of your requests. So it's a net neutral.
3. No one said anything about mobile, so I don't know where you got this from?
4. So browsers should implement a new feature with known privacy implications, and then concurrent with that implement yet another mechanism to prevent the brand new privacy violation from from doing just that? Presumably so that people can then go around complaining about how unnecessarily complex browsers are?
I have a simply question: based on [1] why are you not just using XHR or non-blocking script tags?
2. No, it's a statement that a correct implementation of preloading is free ignore any of your requests. So it's a net neutral.
3. No one said anything about mobile, so I don't know where you got this from?
4. So browsers should implement a new feature with known privacy implications, and then concurrent with that implement yet another mechanism to prevent the brand new privacy violation from from doing just that? Presumably so that people can then go around complaining about how unnecessarily complex browsers are?
I have a simply question: based on [1] why are you not just using XHR or non-blocking script tags?
2. No, it's a statement that a correct implementation of preloading is free ignore any of your requests. So it's a net neutral.
That’s not the way the spec is written for rel=preload.
From § 4.6.7.19 Link type “preload” [1]:
The preload keyword indicates that the user agent will preemptively fetch and cache the specified resource according to the potential destination given by the as attribute (and the priority associated with the corresponding destination), as it is highly likely that the user will require this resource for the current navigation. [PRELOAD]
This sentence is quite clear:
A user agent must not delay the load event for this link type.
The point of preload is to tell the browser “hey—I know you’re busy but this resource is really important for the current page and I need you to prioritize downloading it. I know you’re not aware of this resource because you haven’t parsed that section of the HTML or CSS yet, but trust me, I need you to start downloading it right now.”
The browser is not free to “ignore the request”, which would defeat the purpose of having a directive that tells the browser you want a particular resource to jump to the head of the download queue.
There are other directives that are hints or suggestions, kind of like saying to the browser “if you’re not too busy and you have the bandwidth available, could you download this resource? I don’t need it for the current page but there’s a good chance I’ll need it for the next page the user is likely to access next. It’s not a big deal if you can’t get to it right away.”
[1]: https://html.spec.whatwg.org/multipage/links.html#link-type-...
That’s not the way the spec is written for rel=preload.
From § 4.6.7.19 Link type “preload” [1]:
The preload keyword indicates that the user agent will preemptively fetch and cache the specified resource according to the potential destination given by the as attribute (and the priority associated with the corresponding destination), as it is highly likely that the user will require this resource for the current navigation. [PRELOAD]
This sentence is quite clear:
A user agent must not delay the load event for this link type.
The point of preload is to tell the browser “hey—I know you’re busy but this resource is really important for the current page and I need you to prioritize downloading it. I know you’re not aware of this resource because you haven’t parsed that section of the HTML or CSS yet, but trust me, I need you to start downloading it right now.”
The browser is not free to “ignore the request”, which would defeat the purpose of having a directive that tells the browser you want a particular resource to jump to the head of the download queue.
There are other directives that are hints or suggestions, kind of like saying to the browser “if you’re not too busy and you have the bandwidth available, could you download this resource? I don’t need it for the current page but there’s a good chance I’ll need it for the next page the user is likely to access next. It’s not a big deal if you can’t get to it right away.”
[1]: https://html.spec.whatwg.org/multipage/links.html#link-type-...
So browsers should implement a new feature with known privacy implications…
Gee, I wonder what company makes the vast majority of their revenue by selling ads on their dominant search engine by enabling users to be tracked all over the web? Oh, and this same browser is the only major browser that doesn’t block 3rd party cookies by default?
Safari, Firefox, Brave, Edge provide privacy preserving features to keep their users from being tracked.
It’s in Google’s financial interest to go easy on blocking 3rd party cookies and tacking.
Gee, I wonder what company makes the vast majority of their revenue by selling ads on their dominant search engine by enabling users to be tracked all over the web? Oh, and this same browser is the only major browser that doesn’t block 3rd party cookies by default?
Safari, Firefox, Brave, Edge provide privacy preserving features to keep their users from being tracked.
It’s in Google’s financial interest to go easy on blocking 3rd party cookies and tacking.
So this was solved by adding immeasurable complexity to a feature whose impact is dubious at best and potentially harmful (slow and/or metered internet) at worst.
> potentially harmful (slow and/or metered internet) at worst
iOS and macOS both support low-data mode, which Safari can know about, and disable prefetch in those cases.
iOS and macOS both support low-data mode, which Safari can know about, and disable prefetch in those cases.
This was pre-webkit fork by Chrome, right? is this something outside of webkit then?
Chrome aggressively pushes new "features" with pretty much zero-regard for user privacy.
Prefetch is a particularly good example in that it has no real benefit to the end user, while also providing yet another tool for tracking.
Outside of this there are a bunch of features that are implemented in webkit, that are not enabled in the system frameworks due to them having significant cost to end users.
Outside of this there are a bunch of features that are implemented in webkit, that are not enabled in the system frameworks due to them having significant cost to end users.
I ran the browser bench speedometer2.0 test recently, and was pleasantly surprised to see how much faster safari is than chrome on my macbook air.
I'm not sure why I don't find myself using safari more yet, but maybe soon it'll get there.
I'm not sure why I don't find myself using safari more yet, but maybe soon it'll get there.
I've been using it for years as an alternative to FF, and the only things that sometimes feel sluggish are Google web apps. Honestly, I blame FUD for that one, not the browser itself. The battery life is pretty good too.
Extension-wise, I only have Hush and Adguard installed.
Extension-wise, I only have Hush and Adguard installed.
Google is known to sabotage other browsers by slowing down or breaking its apps in all but Chrome. See this thread from Jonathan Nightingale: https://twitter.com/johnath/status/1116871243301625856
Edit. Johnathan Nightingale was General Manager and Vice President of the Firefox group at Mozilla. He knows what he's talking about.
Edit. Johnathan Nightingale was General Manager and Vice President of the Firefox group at Mozilla. He knows what he's talking about.
That's a welcome surprise that they've added support for the very handy "Scroll to Text Fragment" feature, as seen in Chrome.
https://webkit.org/blog/13399/webkit-features-in-safari-16-1...
https://webkit.org/blog/13399/webkit-features-in-safari-16-1...
And it’s 100% compatible with Chrome’s implementation: https://wpt.fyi/results/scroll-to-text-fragment?label=experi...
Now that I've tried it, is it just me or have they only implemented half of the feature? i.e. you can successfully visit such a link, but there's no way to create such a link yourself?
Really looking forward to playing around with this passkeys thing. If I understand it correctly, I can't implement it as the only authentication method for my website unless I'm okay with locking my users down to one single device?
Edit: to clarify, if my user set up passkey on their iPhone and that's the only method of authentication for my website, they just wouldn't be able to sign in if they lost that iPhone? The key can't be recovered, transferred or backed up? I'm okay with that (I own several yubikeys myself), just want to make sure I understand it correctly.
Edit: to clarify, if my user set up passkey on their iPhone and that's the only method of authentication for my website, they just wouldn't be able to sign in if they lost that iPhone? The key can't be recovered, transferred or backed up? I'm okay with that (I own several yubikeys myself), just want to make sure I understand it correctly.
> to clarify, if my user set up passkey on their iPhone and that's the only method of authentication for my website, they just wouldn't be able to sign in if they lost that iPhone?
That used to be the case. Since iOS 16 they are also synced via the iCloud Keychain: "Passkeys on iPhone require that you use iCloud Keychain. If you don’t have iCloud Keychain turned on when you try to save a passkey, you’ll be asked to turn it on. Passkeys also require that two-factor authentication is enabled for your Apple ID."
https://support.apple.com/guide/iphone/sign-in-with-passkeys...
That used to be the case. Since iOS 16 they are also synced via the iCloud Keychain: "Passkeys on iPhone require that you use iCloud Keychain. If you don’t have iCloud Keychain turned on when you try to save a passkey, you’ll be asked to turn it on. Passkeys also require that two-factor authentication is enabled for your Apple ID."
https://support.apple.com/guide/iphone/sign-in-with-passkeys...
Perfect, thanks!
It’s going to take a while before there’s a critical mass of passkey users to make this viable.
Because it’s based on Webauthn, I believe a website can fall back to using a compatible security key (like a YubiKey) as authentication.
Because it’s based on Webauthn, I believe a website can fall back to using a compatible security key (like a YubiKey) as authentication.
[deleted]
Is there an easy way to turn off web push entirely so I don't get spammed with spamification requests?
Is there an easy way to turn off web push entirely so I don't get spammed with spamification requests?
Short answer: yes. In Safari 16.1, select Preferences > Websites and uncheck “Allow websites to ask for permission to send notifications”.
Details about WebKit’s Web Push implementation and how privacy is handled [1]:
[1]: https://webkit.org/blog/12945/meet-web-push/
Short answer: yes. In Safari 16.1, select Preferences > Websites and uncheck “Allow websites to ask for permission to send notifications”.
Details about WebKit’s Web Push implementation and how privacy is handled [1]:
[1]: https://webkit.org/blog/12945/meet-web-push/
Yes, as others said.
Also, in Safari you will not get spammed by requests for permission to send notifications. A website or web app can only ask for permission _after_ you've indicated interest with a gesture — like clicking on a "subscribe" bell icon, or a button that says "notify me". They are not allowed to ask you until you've taken the first step.
Also, in Safari you will not get spammed by requests for permission to send notifications. A website or web app can only ask for permission _after_ you've indicated interest with a gesture — like clicking on a "subscribe" bell icon, or a button that says "notify me". They are not allowed to ask you until you've taken the first step.
There is a setting in Preferences > Websites > Notifications to disable notifications entirely.
Still no regex lookbehinds, I dream of the day when (if) they'll ship in Safari.
love Safari but literally cannot not make it my daily driver unless webRequestBlocking is supported (mainly for ublock origin).
Seconded. Their excuses for removing support are baffling (guess what? most current Safari adblockers still request access to "data from all websites", which is exactly what "Content Blockers" were supposed to prevent. So now, instead of open-source uBlock having access to all websites, people use proprietary extensions that have the same access. Ugh.)
You may want to check Orion browser in this case. (dev here)
I was really hoping import maps would be merged in to Safari as it has already landed in webkit:
* https://bugs.webkit.org/show_bug.cgi?id=220823
* https://github.com/WICG/import-maps/blob/main/README.md
* https://bugs.webkit.org/show_bug.cgi?id=220823
* https://github.com/WICG/import-maps/blob/main/README.md
We still have to wait a bit longer for web push on mobile safari. I hope it's worth the wait
Just lost a sessions with about 200 Tabs updating to Safari 16.1. Sigh.
It seems the criticism on Safari hasn't evolved alongside WebKit's efforts. It's true that WebKit is no longer lagging behind web standards (with the notable exceptions of PWAs and prefetch). Though I'll note that much of the criticism (see: IndexedDB) wasn't Apple lacking standards support, but having buggy implementations. I can't speak to Safari's dev tools because I just use Chrome's.
But if critics keep focusing on webcompat, they might comfort the WebKit team into thinking that all the criticism is unwarranted, and that Safari has caugh up. That's not the case when it comes to the user experience, where Safari still lags far behind.
Just weeks ago, Safari lost me a few tabs, twice. The tabs kept the favicon, but became "Untitled", and when you clicked on them, they were just blank, and the "back" button was disabled. Does this version fix it? No clue, because they never acknowledged that bug publicly. Never had a bug like that on Chrome, in the decade I've used it.
Safari still doesn't allow users to select multiple tabs to move them to other windows or move them to tab groups. Firefox and Chrome both can.
The "back" button is still finicky. The button bizzarely feels more reliable than the trackpad gesture. The full-page animation makes it feel much slower than Chrome, which doesn't have a page-back animation except a small left arrow no the side. There's a huge bug, that's survived for many years and which I encounter very frequently: when you Google something, click on a result, then go back, you end up at the Start Page rather than the Google search, which isn't even in the History. How?
Extension support on iOS is far better than competitors, but on the Mac, Apple's clearly saying "fuck you" to extension developers. Forcing devs to pay, making basic APIs unavailable without good reason (webRequest blocking; they really should just implement whatever gorhill tells them to; I thought they disliked ads and tracking?), and cluttering users' Applications folders with browser extensions unlike every other browser. Why can't I use the Bypass Paywalls Clean extension with Safari? uBlock Origin? SingleFile? There's a long-tail of extensions that Safari will never support, due to the Safari team's practices.
And why lack support for profiles? I don't want to switch user accounts; I just want to be able to segregate work and personal, so my URL autocomplete doesn't show personal stuff at work. That's a basic requirement in the era of screen sharing and streaming.
Tab groups are an encouraging feature, that shows Apple cares about power users, but Safari still feels too "restricted" and rigid. There's a strong feeling that "Apple knows best" and feel they can dictate the user experience, which just doesn't work for something as personal as a browser. No, it wouldn't be "un-Apple-like" to roll out Profiles, or proper extension support that don't clutter the apps folder. Worried about malware extensions? Then improve your analytics, and rely on Apple's ability to remote-uninstall bad extensions, like Firefox and Chrome have done. They're just hurting power users, with little benefit for average users who mostly don't install extensions anyway.
But if critics keep focusing on webcompat, they might comfort the WebKit team into thinking that all the criticism is unwarranted, and that Safari has caugh up. That's not the case when it comes to the user experience, where Safari still lags far behind.
Just weeks ago, Safari lost me a few tabs, twice. The tabs kept the favicon, but became "Untitled", and when you clicked on them, they were just blank, and the "back" button was disabled. Does this version fix it? No clue, because they never acknowledged that bug publicly. Never had a bug like that on Chrome, in the decade I've used it.
Safari still doesn't allow users to select multiple tabs to move them to other windows or move them to tab groups. Firefox and Chrome both can.
The "back" button is still finicky. The button bizzarely feels more reliable than the trackpad gesture. The full-page animation makes it feel much slower than Chrome, which doesn't have a page-back animation except a small left arrow no the side. There's a huge bug, that's survived for many years and which I encounter very frequently: when you Google something, click on a result, then go back, you end up at the Start Page rather than the Google search, which isn't even in the History. How?
Extension support on iOS is far better than competitors, but on the Mac, Apple's clearly saying "fuck you" to extension developers. Forcing devs to pay, making basic APIs unavailable without good reason (webRequest blocking; they really should just implement whatever gorhill tells them to; I thought they disliked ads and tracking?), and cluttering users' Applications folders with browser extensions unlike every other browser. Why can't I use the Bypass Paywalls Clean extension with Safari? uBlock Origin? SingleFile? There's a long-tail of extensions that Safari will never support, due to the Safari team's practices.
And why lack support for profiles? I don't want to switch user accounts; I just want to be able to segregate work and personal, so my URL autocomplete doesn't show personal stuff at work. That's a basic requirement in the era of screen sharing and streaming.
Tab groups are an encouraging feature, that shows Apple cares about power users, but Safari still feels too "restricted" and rigid. There's a strong feeling that "Apple knows best" and feel they can dictate the user experience, which just doesn't work for something as personal as a browser. No, it wouldn't be "un-Apple-like" to roll out Profiles, or proper extension support that don't clutter the apps folder. Worried about malware extensions? Then improve your analytics, and rely on Apple's ability to remote-uninstall bad extensions, like Firefox and Chrome have done. They're just hurting power users, with little benefit for average users who mostly don't install extensions anyway.
They are late to the game as always. It seems like Chromium and Firefox are the first to implement, and Safari is consistently last. There are a few standards that Safari has been first to, but it is the exception.
Sometimes duplicate or wasteful features[0], but hey, Chrome's got those features!
Meanwhile, on interoperability[1], Firefox and Safari are currently at 84, while Chrome is at... 75. Once they update with this new release, Safari should climb to 89[2].
Being first to things isn't always the great thing you're suggesting, if those things aren't actually being asked for--or wanted.
0. https://lists.webkit.org/pipermail/webkit-dev/2021-March/031...
1. https://wpt.fyi/interop-2022?stable
2. https://wpt.fyi/interop-2022
Meanwhile, on interoperability[1], Firefox and Safari are currently at 84, while Chrome is at... 75. Once they update with this new release, Safari should climb to 89[2].
Being first to things isn't always the great thing you're suggesting, if those things aren't actually being asked for--or wanted.
0. https://lists.webkit.org/pipermail/webkit-dev/2021-March/031...
1. https://wpt.fyi/interop-2022?stable
2. https://wpt.fyi/interop-2022
That first link is a thing of beauty.
Also, it's terrifying because it's just one of hundreds of standards that WebKit (and Firefox) might not have the time and resources to fight.
Also, it's terrifying because it's just one of hundreds of standards that WebKit (and Firefox) might not have the time and resources to fight.
This is, of course, untrue.
Chrome ships hundreds of new web APIs a year. Most of them are Chrome-only non-standards. Firefox and Safari are more closely aligned: https://web-confluence.appspot.com/#!/confluence
Chrome ships hundreds of new web APIs a year. Most of them are Chrome-only non-standards. Firefox and Safari are more closely aligned: https://web-confluence.appspot.com/#!/confluence
I was specifically referring to CSS features as proposed by standards bodies.
Every browser has instances of being the holdout on features, Safari does not stand out, especially amongst CSS features. Safari hasn't shipped touch-action, overflow-anchor, media queries range syntax. Chrome hasn't shipped the new viewport units, font-variant-alternates, or CSS subgrid. Chrome not supporting CSS subgrid is far more consequential than any CSS feature Safari is the holdout on.
Edit: Safari also has no support for CSS counter styles or CSS paged media while Chrome and Firefox have at least partial support. Again, those don't seem particularly consequential features for moving web design forward.
https://caniuse.com/?compare=chrome+106,safari+16.0,firefox+...
Edit: Safari also has no support for CSS counter styles or CSS paged media while Chrome and Firefox have at least partial support. Again, those don't seem particularly consequential features for moving web design forward.
https://caniuse.com/?compare=chrome+106,safari+16.0,firefox+...
CSS counter styles or CSS paged media while Chrome and Firefox have
When I read this, I turned on css counter styles on my iPhone:
Settings > Safari > Advanced > Experimental features.
There are a lot of in-development web features that can be enabled.
When I read this, I turned on css counter styles on my iPhone:
Settings > Safari > Advanced > Experimental features.
There are a lot of in-development web features that can be enabled.
If a feature is not enabled in a browser by default, it doesn't count as "Yes, supported." Sites can't be designed expecting users will all go into their browser's experimental features list and turn things on.
Some CSS features can be used even without widespread browser support because the content's meaning isn't changed in browsers that don't support the feature; border-radius is a classic example. For something like CSS counter styles, if an ordered list is equally well-understood with the default numbers or the custom styles, they can be fine but it's easy to think of examples where meaning would be lost without the counter styles.
Some CSS features can be used even without widespread browser support because the content's meaning isn't changed in browsers that don't support the feature; border-radius is a classic example. For something like CSS counter styles, if an ordered list is equally well-understood with the default numbers or the custom styles, they can be fine but it's easy to think of examples where meaning would be lost without the counter styles.
If a feature is not enabled in a browser by default, it doesn't count as "Yes, supported." Sites can't be designed expecting users will all go into their browser's experimental features list and turn things on.on
I didn't claim this was a supported feature, just that it wasn't accurate to suggest that WebKit has no support for some of these features that seem to be missing. They are being worked on and will be turned on by default pretty soon.
I didn't claim this was a supported feature, just that it wasn't accurate to suggest that WebKit has no support for some of these features that seem to be missing. They are being worked on and will be turned on by default pretty soon.
By caniuse’s measure, being behind a flag is a ‘No’ for the reason I gave.
Being available as an experimental feature does not mean its release is imminent, there are ones that have been there for years. Thankfully, it’s not like they’re in a queue, some are released after only a few months.
Being available as an experimental feature does not mean its release is imminent, there are ones that have been there for years. Thankfully, it’s not like they’re in a queue, some are released after only a few months.
Why does it matter if they're first to implement a standard?
Because Safari is gatekeeping not innovating and implementing W3C standards.
False.
In case nobody noticed, the WebKit team kicked ass by shipping a ton of new features this year:
* dialog element
* lazy loading
* inert
* :has() pseudo-class
* new viewport units
* Cascade Layers
* focus visible
* accent color
* appearance
* font palettes for color fonts
* BroadcastChannel
* Web Locks API
* File System Access API
* enhancements to WebAssembly
* support for Display-P3 in canvas
* additions to COOP and COEP
* container queries
* subgrid
* web push
* shared workers
* CSS Offset Path
* AVIF
* Passkeys
In case nobody noticed, the WebKit team kicked ass by shipping a ton of new features this year:
* dialog element
* lazy loading
* inert
* :has() pseudo-class
* new viewport units
* Cascade Layers
* focus visible
* accent color
* appearance
* font palettes for color fonts
* BroadcastChannel
* Web Locks API
* File System Access API
* enhancements to WebAssembly
* support for Display-P3 in canvas
* additions to COOP and COEP
* container queries
* subgrid
* web push
* shared workers
* CSS Offset Path
* AVIF
* Passkeys
What are they gatekeeping here?
Web standards and features. I assume you haven't heard of them intentionally limiting PWAs?
Huh, I didn’t realize that there was a “web standards and features” standard, or a PWA specification - could you provide the urls?
Or alternatively actually answer the question like an adult rather than parroting the standard Apple hates the web nonsense.
Or alternatively actually answer the question like an adult rather than parroting the standard Apple hates the web nonsense.
Firefox v2 (2006) and Chrome v8 (2010) have had this feature for well over a decade.
A little more on this topic: https://nitter.net/Dieulot/status/1574763586055987200#m
EDIT: I realize there is an argument that this might be used for ad tracking but thought that was solved with some type of cache sandboxing that other browsers already have.
EDIT2: People keep saying it’s a privacy issue. Am I wrong in understanding that cache sandboxing mitigates this privacy concern?
https://news.ycombinator.com/item?id=27365608