The image at the top is a great overview, but sadly it's a image, even though implementing it with HTML + CSS would have been trivial. Sad to see a browser engine not using browser technologies and instead opt for images. Extra sad that instead of putting the same text in the alt text, it just describes that it's a lot of text describing all the new features (and in it, the author confuses what the image is, vs what a "word cloud" is), poor screen-readers who don't get that nice overview.
Anyways, for the rest of you, I passed it through OCR, so probably some mistakes somewhere:
Webkit Features in Safari 16.0 / Lazy Loading Images / appearance CSS property / Removed Webkit Prefixes /
ResizeObserverSize / Subgrid / CSS Containment / Fullscreen API in WKWebView / accent-color / Scroll Behavior /
Shared Workers / New Viewport Units / Font Palettes for Color Fonts / Container Queries / ic Unit / :has() Pseudo Class /
Cascade Layers / Web Inspector Extensions / New Web Extension APIs / Manifest version 3 / Discrete Animation /
Web Animations Composite Operations / Overscroll Behavior / Web Inspector CSS Variable Grouping / AVIF /
Flexbox Inspector / Dialog Element / Inert Attribute / New Apple Pay payment options / structuredClone(value) /
text-decoration-skip-ink / CSS Motion Path / Screen Capture Improvements / SharedArrayBuffer / Object.hasOwn() /
findLast() / findLastIndex() / at() method / text-align-last / Internationalization Updates / Form Improvements /
Passkeys / Web Push for macOS Ventura / :focus-visible Pseudo Class / CSP 3 / display: contents accessibility /
Wide Gamut HTML Canvas / <form>.requestSubmit() / File System API / BroadcastChannel / Web Locks API /
Improved Web App Manifest Loading / Web App Manifest Icons / :has(:target) / Navigation Preload in ServiceWorker /
worker-src CSP directive / WebRTC Perfect Negotiation / In-band Chapter Tracks / SharedArrayBuffer /
Private Click Measurement Updates / requestVideoFrameCallback() / Shadow Realms / Web Inspector Alignment Editor /
MSE in WKWebView for iPadOS / resolution media query / Increased WASM Memory Limit / <input>.showPicker()
Faster VoiceOver / WASM Zero-Cost Exception Handling / Cross-Origin-Opener-Policy / Cross-Origin-Embedder-Policy
No need to "pass it through OCR" if you're viewing it in Safari :-)
(because it OCR's all images anyway, mobile and desktop both—I browsed to the page and select-all'd the image text just like it was HTML—still, they should have just made it HTML)
The Android activity switcher has been able to OCR whatever is displayed on the screen since 2018. Nice to see iOS added something like it last year. It's come in handy loads of times.
I wasn’t aware of that but it doesn’t surprise me given some of the other image intelligence stuff Google has had that Apple is slowly catching up on like recognizing animals/objects.
Already it’s saved me a bunch of time numerous times.
Apple tends to be a bit behind Google on AI since they like to do things on-device for privacy, etc..
Also sometimes they take their time in implementing something if they don't think they have the right UI for it (such as copy & paste, which was missing on the original iPhone.)
But I agree: Live Text is nice and it works just the way you'd expect it to.
Note that speech to text and voice assistant functionality happens on device on Android since 2019 for privacy (https://blog.google/products/assistant/next-generation-googl...), while iOS continued to send data to Apple until 2021 (https://www.theverge.com/2021/6/7/22522993/apple-siri-on-dev...). Neither privacy nor UI were an issue. Android used the on-device speech to text to transcribe phone calls, so I never have to listen to menu options repeat (though it doesn't yet automatically enter my SSN or account number), automatically caption arbitrary audio playing on the device, etc. These are other features I use frequently that Apple will get to eventually, but it's not because of privacy or UI.
I just went googling for it, wondering if the Android version is on-device or sends data off to servers to do it, and couldn't find anything about a device-wide OCR on Android. Guides to developing with MLKit, and something about the feature specifically in Google Docs on Android, but nothing about the device-wide feature. Bizarre.
Same search but "apple" instead of "android" (not even iOS, which is what I meant to search but messed up) turned up tons of hits about the feature on iOS and macOS, and confirmed what I thought, which is that it's on-device.
[EDIT] Mind, I'm not saying it doesn't exist, just that it's weirdly-difficult to find anything about with searches on Google's own search engine.
Ahhh, container queries... here at last. Passkeys look very interesting as well. What kind of adoption do people expect passkeys to get? I had read that it was a general standard rather than Apple specific. I've gotten used to password managers but they've always felt like a man in the middle.
FIDO is the general standard, though I'm unsure how Apple's implementation differs. The tricky aspect of Passkeys is that there doesn't seem to be an easy way to use them on non-Apple devices (IMHO not a deliberate lock-in, but a hard problem in general). I expect adoption to be slow because of this, in addition to the general problem of sites needing to adopt new authentication flows.
> The tricky aspect of Passkeys is that there doesn't seem to be an easy way to use them on non-Apple devices (IMHO not a deliberate lock-in, but a hard problem in general).
I think you're right that password managers will probably evolve to handle syncing across devices. I was thinking about how iCloud Keychain doesn't work with non-Apple devices (solvable with third party password managers, I assume).
If you're using Safari there's password management builtin, though obviously that assumes you're Apple+iCloud+safari ecosystem only which is an infeasible restriction for many people.
The passkeys API is afaict actually a spec to handle hardware token based login which Safari uses the builtin SEP (or the SE? I can honestly never recall which is which) so it's more streamlined than digging around for a token. But then I don't know how it (either the specification or the safari implementation) handles multiple devices. But again it seems possible that you hit similar "are you a safari only user?" ecosystem issues.
If you're using Safari there's password management builtin, though obviously that assumes you're Apple+iCloud+safari ecosystem only
Safari actually uses Keychain, which has been part of macOS since it existed and long before Safari and iCloud were even thought of.
But again it seems possible that you hit similar "are you a safari only user?" ecosystem issues.
Passkeys is WebAuthn, an industry standard that uses public key encryption. Your public key is your identity and the private key is essentially your password. It doesn’t require a secure element or anything like that.
There’s no reason why Passkeys created on a Mac can’t work on Windows or Linux that have browsers and password managers that support Passkeys/WebAuthn.
> Safari actually uses Keychain, which has been part of macOS since it existed and long before Safari and iCloud were even thought of.
I know how safari and keychain works, and my statement stands as a reasonable summary of the end user experience.
Keychain is the mechanism by which passwords are stored, but the integration into the browser is only available in Safari - you can manually open and use KeychainAccess to get the passwords for use in other browsers but that is far from what is expected from modern password manager UI - the UI for this path is even worse on iOS. To get the syncing between devices that people want from password managers using the safari password system requires an iCloud account.
> Passkeys is WebAuthn, an industry standard that uses public key encryption
The generation using the secure element/touchid seems to be safari only, and the key material is as you say stored in keychain, which other browsers do not use and so do not have access to. So using them has the effect of tying you to the safari/apple ecosystem.
Question of ecosystems are a matter of "how does an end user actually use a feature?" not "could a sufficiently skilled user use the feature across multiple ecosystems?".
Other browsers could use Keychain if they wanted to; it’s a public api; there’s even a command line tool.
Other browsers have their own features for syncing passwords, extensions, etc.
There’s no reason why a future install process for Firefox, Chrome, Brave, etc. couldn’t offer to import Safari’s Passkeys just like they do bookmarks.
But they don’t and the point is you can’t use Safari on one machine and Firefox or chrome on another (although someone said there might be an extension for chrome in windows at least?).
But very recent WebAuthN with (almost) all the extras. The featureset needed for passkeys doesn't seem to be very well supported on anything but Apple systems
I mean that’s a tall ask, even google just does a YT video and a blog post and allow the enthusiast community to truly do the heavy lifting. Most of the features have been posted on this very site already.
Very excited to see SharedWorkers return to safari - so many buggy work arounds can be deleted. A really great use case for SharedWorkers is to handle your websocket connection- sharing it between all open tabs. This is something ServiceWorkers can’t be used for but is great for SharedWorkers
And Web Push should come in 2023 (according to https://www.apple.com/ios/ios-16/features/ ). Which I both love and hate. As a developer I like it as it makes PWAs even more viable but as a user I have notifications in all browsers disabled anyways. I wonder how this "opt-in" setting will be exposed.
Overscroll Behavior will make my life so much easier when I have to implement a modal that can scroll. You need stuff like body-scroll-lock [1] which will do a lot of different tricks and has to be implemented just right. Now we only need to add overscroll-behavior: contain; and we're done.
When you swipe back on the trackpad to go back on my M1 MacBook Air, you must wait for the animation to end before taking any other action. That means there's basically a 0.5 second lag every time you go back. This is unacceptable. Safari for the Mac has had this issue for years and I am honestly shocked that Apple haven't fixed it. It means that they themselves don't use their own product.
Over the last 5 years I have been through, in that order:
- Safari
- Chrome
- Safari
- Firefox
- Safari
- Firefox
I keep trying to stick to Safari because of the resource usage and OS integration, but it just becomes unusable. Very very very slow. Difficult to integrate decent extensions or alternatives (e.g. RedditEnhancementSuite, Ublock Origin), and a distinct feeling of sluggishness.
I have changed back to firefox (in the last 3 months) after 7 or 8 months trying to use Safari again. I just couldn't deal with it anymore. A pity, really.
I just checked, and I have usage statistics (from the Timing app) on application usage since September 2017.
Chrome: 54%
Firefox: 32%
Safari: 13%
These stats are inherently a bit skewed because I still use chrome for some development, or firefox. So Chrome should come a bit down and Safari go a bit up. Also, my overall browsing usage has decreased and the data isn't adjusted for that. I used to be in "the browser" a lot more when I used chrome than now.
I don't intend to go back to chrome. I can't stand google, and at the time what really tipped me over the edge (to Safari) was how awful their integration with the macOS play controls were. Chrome would assume putting or taking my airpods from my ears was the same as pressing play/pause, regardless of anything else. So sometimes I'd put them in my ears and videos would stop. Sometimes they'd start. Whatever. It was a mess.
I would suspect it's more gesture based navigation is uncommon among engineers/technical folk vs cmd+[,]. That said the animation shouldn't be stopping other actions - that's imo the issue with any kind of animation triggered by UI actions in general.
(This has consequences on how menus are rendered and the Dock will look a bit less nice, and you'll loose this blurry, semi-transparent overscroll in Safari, but you get an overall cleaner and more responsive UI.)
Edit: No, I just tried with full transparencies enabled, but I still get no animation and no delays. That's not it.
Anyways, for the rest of you, I passed it through OCR, so probably some mistakes somewhere: