New WebKit features in Safari 15.4
webkit.org
webkit.org
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
In 2018 Domenic Denicola mentioned that it's possible dialog should be fully removed as there's no interest in implementing it: https://github.com/whatwg/html/pull/4184#issuecomment-440405...
Fast forward to 2021, and Chrome breaks the web by removing built-in alert/prompt/confirm dialogs: https://dev.to/richharris/stay-alert-d Now the same very people, including Domenic, were arguing that alert is bad for security, bad for the Javascript engine etc. It looks like browser implementors agreed to remove those from all three browsers. Chrome was just the first.
And yet there's literally no replacement for those.
Skip to Safari 15, and we're suddenly getting <dialog> even though:
- Safari (and Mozilla) have been opposed to the current state of the spec for 10 years now
- Safari (and Mozilla) have had no interest in implementing this element as it's currently specced
- None of the decade-long issues with dialog have been fixed, including these accessibility issues
So something tells me it's there only because of the planned removal of the built-in alert/confirm/prompt, and not for any other reason.
Thanks to such attitudes, Safari remains the "new IE", the problem browser for which developers must find workarounds.
(1) e.g. https://github.com/WICG/webcomponents/issues/509 and other forums besides
More like the non-Chrome browser for which Chrome developers must find workarounds. I can't remember encountering a Safari specific problem in the tens of websites I have developed in the last years. Now sure I understand the pain if you are developing web apps instead, but in that case maybe it's time to assume Chrome is an app platform (OS ?) and not just a browser, and simply only target that platform and don't try to shoehorn the web into it?
The web itself is an app platform. The only browser preventing it to happen on mobile is Safari. Have a look at the desktop. There, web apps have replaced most native apps long ago.
And indeed when we have a look at the desktop it further proves the point, Electron apps ship their whole execution platform, basically an OS inside an OS, and it's Chrome. So the divorce between Chrome the app platform and the web has already started. Safari is a blessing for me because it force that issue to crop up and be discussed, instead of just letting the web slowly become the Google platform.
It's not. And frankly will never be.
> The only browser preventing it to happen on mobile is Safari.
It's not preventing anything
> look at the desktop. There, web apps have replaced most native apps long ago.
What a strange fantasy world you live in.
I do admit sometimes I feel Safari to be lagging behind, but I think it's a far cry from the 'new IE'. At the very least it's not a given that it's the problem browser for developers.
However, in my view: as one of the four stewards of WHATWG, Apple have an obligation to either implement the standard, or propose a convincing alternative that the steering group can adopt.
I don’t know what’s more embarrassing; that Apple tried to use market power to modify a standard after failing to do so in committee, or that after six years even that strategy was a failure. Either way it all smacks of institutional arrogance.
That's how how standards work
If Apple do not wish to implement the standard, they should leave the steering group.
No, they shouldn't.
There was another standard, HTML Imports. It was agreed on, but then Mozilla decided not to implement them. Should Mozilla leave the steering group, too?
That is, there hasn’t been a new version of Safari Technology Preview, which is what the experimental numbers are based on.
With "stable" and actually-consumed versions of browsers (a more important goal for "interop"), you'll see:
- FF: 74
- Chrome: 66
- Safari: 50
Will 15.4 be tested?
15.4 should show up in day or two, there's a bunch of latency in how those metrics are generated currently…
The only reason dialog is back (even though Safari and Firefox were against it for many solid reasons) is that browsers want to remove alert/confirm.
I was really hoping this announcement would include support for push notifications for PWAs. I've been trying to build a few Discourse forums and they work very well as PWAs except for the fact that iOS doesn't support PWAs sending push notifications.
So here's to hoping the next iteration will.
On Android I can log into Facebook's website, and receive push notifications via the web-browser. On iOS my choices are either the native iOS app (which has substantially more data hooks) or nothing at all.
Essentially browser Push Notifications increase my privacy.
PS - I am sympathetic to complaints about push notification request spam, but that feels like a solvable issue without throwing the dishes out with the bathwater. You shouldn't need an "app" just for notifications.
PWAs would increase security all around compared to native apps, but that might cut into App Store revenue.
Are you joking? https://www.macrumors.com/2022/02/03/facebook-10-billion-in-...
[1] https://developer.apple.com/app-store/user-privacy-and-data-..., “Asking Permission to Track”
I don't understand why that's unexpected when a core idea of the App Store model is that Apple can better protect its customers against bad actors.
> PWAs from the beginning would have prevented Facebook from collecting data for the last decade in the first place…
I'm not sure how you arrived at that conclusion. My assumption is that a rounding error's percentage of Facebook users choose the PWA over the native app on platforms which support both, like Android. If you have actual data on this, I'd appreciate hearing about it.
I don't really see how % of users plays into it. I mean it's great the App Store is finally on board with being more strict on blocking user tracking after a decade of business but as long as more than 0 wanted to fix it before and couldn't because of the PWA and/or app sources policies then then policy around not-allowing those is based on protecting the App Store regardless how often privacy is brought up as the reason.
I mean it's great they protect it for the customers that fall towards the default option now don't get me wrong but while nice that doesn't really have anything to do with why all users were forced through the App Store before or after the policy change.
My suspicion is that they internally treat it as their own third party browser - e.g. they don't want to give it more entitlements/capabilities than a Firefox or Chrome browser would have from the iOS app store.
My suspicion also is that they have had a bit more wood behind the arrow to get media APIs working lately due to pushing large third-party cloud game subscription services to use the browser, and the regulatory scrutiny that likely brought on.
> Web App Manifest improvements include ensuring the browser always fetches the manifest file during page load instead of when the user chooses to “Add to Home Screen” from the Share menu.
If you mean html/css prompts rather than actual browser prompts: they already do that.
They could use their differential privacy to only allow for sites that have a reasonable opt in rate, and global opt out.
It’s pretty annoying.
- the dialog is model
- it’s small, and drops down from the top (a “reverse toast”?)
- I frequently use screen zoom So am typically unable to see the top of any window because I’m reading content
- I click a link, the page loads, the “toast” drops down but I don’t see it, suddenly nothing on the page works
For 99% of sites which ask for permission the answer is “no”. So that’s a lot of annoying web sites.
Is it really going to mean that much to web apps? I’m assuming it will work pretty much like push notifications on desktop, which is an awful UX.
To provide just one example, I released a turn-based word game as a PWA two years ago. With no option for native push notifications on iOS, I decided to email players to notify them each time it was their turn in a game.
Despite my domain having full support for DKIM, SPF, and DMARC, the usual problems of email were still a huge pain: Some domains (I'm looking at you hotmail.com) considered everything spam. In some email clients, the design of the emails looked totally wrong. Some of the more active players complained (rightfully so) that their inbox was filling up with these emails.
Sadly, the overwhelming majority of games never got past one or two moves, in part because one of the two players didn't see the email that it was their turn.
So yes, it would really, really help small businesses like mine if Safari would catch up here!
[0] eg, https://www.macworld.com/article/610673/ios-15-4-safari-push...
It’ll probably be officially announced at Apple’s World Wide Developers Conference in June.
Agreed.
Not being on by default likely means it's also buggy and incomplete.
... I assume WebKit has had support for this for a long time, since Safari on macOS has long supported push notifications.
Safari on macOS does not support the web Push API[1]. Apple has a proprietary Safari Push Notification service that requires all notifications to go through Apple's servers first[2].
[1] https://caniuse.com/push-api
[2] https://developer.apple.com/notifications/safari-push-notifi...
I've completely given up any kind of hope for iOS.
I hoped for years iOS would do reasonable things like allowing side loading or multitasking or push notifications. Apple knows these things would improve the platform, they don't do them because it would cut into their profits. If these features are ever added to the platform they will be handicapped in some way that makes them almost useless.
[0] https://www.forbes.com/sites/siladityaray/2021/08/27/apple-a...
Might as well get started on those uBlock filters!
dialog[class*="newsletter" i]
dialog[id*="newsletter" i]
dialog[class*="social" i]
dialog[id*="social" i]
dialog[id*="mailchimp" i][x] Block javascript popups and scrollovers
[x] Block newsletter and notification solicitations
[x] Really block all forms of auto-playing video in a way that actually works
This is SUPER nice... there are other hacks like IndexedDB or localStorage but this is way better!
But the frustrating part her is that we're excited about Webkit finally starting to catch up.
Chrome is just perpetually innovating and then Webkit is constantly lagging.
Supporting Safari is BY FAR the hardest part of my job.
I’m still waiting for regex lookbehinds, a ES2018 syntax that I can’t use. Literally Safari does not execute the whole file if you use such regex literals.
No. Chrome is perpetually in Fire and Motion.
Chrome is not the standard, https://v4.chriskrycho.com/2017/chrome-is-not-the-standard.h...
Browser diversity isn't work2 as advertised. It's just Google inventing things that other companies only get a year later, or totally reject. Mozilla needs to start trusting its users to have access to features like Google does, and Apple needs to allow third party browsers without WebKit.
Nor would I be nerfing ublock if I had the choice, browsers are already nerfed way more than enough, and if it were up to me we would have full pluggable network stacks as extensions, with access to raw sockets, so we had a vague chance at ever having a P2P internet that isn't blockchainified.
Anecdote: I tried (limited) CSS validation to through a regexp some time ago, and it worked, except that Chrome’s implementation jumped from a few 100ms to over 5 minutes on adding a single character. Made the whole thing quite useless.
OTOH get look behind perf to not be horrific is challenging
I could have done it without a lookbehind but occasions to use it are quite rare to me :)
I care as much about outdated browsers as I care about Internet Explorer. If you want a modern experience, buy devices that allow you to update the browser (or complain to your manufacturer that you can't).
Every other website has given up on my old second hand iPad, there are no new apps available for it and the old APIs are all shut down. Why should I still care about it as a web developer? It's still a nice device to read PDFs on.
On ChromeOS devices you usually can install a regular linux distribution though.
A shame, really, because Linux could keep the Chromebooks that have somehow become too outdated alive for a few more years. Luckily Safari (and to some extend Firefox) is out there lacking common features that were in Chrome years ago, so polyfills will probably still be used for a few years.
Cynical me has observed this annual pattern where Apple just before their developer conference suddenly becomes "genuinely" interested in the web community and actively listens to feedback. Then, things get back to normal, which means they don't implement anything, all feedback goes to /dev/null, documentation is lacking and bugs are never solved.
It's hard to get past this cynical angle because even in this release they're boasting about how they're "first" to implement something, whilst it remains to be the browser lagging years behind. Typical Apple, fluffy marketing with zero self-reflection.
I did see there's lots of webkit vacancies at Apple now, so one can hope things are changing for the better. Probably because it looks better to regulators.
This doesn’t make sense to me. Features takes time to discuss, roadmap, argue , implement, test, and ship. These things aren’t something you just ramp up just before their developer conference. I would be furious if I were a WebKit developer and told I don’t implement anything or take feedback all year up until a Yearly conference. Especially when Safari updated 7 times last year alone.
Apple not taking feedback or taking it and it being completely pointless is well documented behavior. This guy...
...has basically been doing Apple's job for ages. Testing releases, documenting endless bugs, providing feedback, usually leading to absolutely nothing at all. Recently, he kept score from what was actually handled based on last year's feedback. It was close to nothing. Which is business as usual, it's like talking to a brick wall.
Things couldn't be more dramatically different with the Chrome team. When I register a bug there, I get feedback within hours. They will scrutinize it immediately and confirm if its reproducible or not. They will indicate if its per spec or not, refer to discussions and assign it to a group/member when it's a valid bug. If it's anything remotely serious, it's often solved within 2 releases, so within 12 weeks.
Further, one can directly interact with the Chrome team on Twitter and I regularly have long email conversations with them by personal email. They are accessible and take your feedback serious. Apple is the exact opposite.
As for Safari updates, they're usually meh. Small list of bug fixes and some web inspector improvements. Hence my remark that this is an unusually valuable release.
I try really hard to love Safari, I really do, but it's just a shitshow outside of battery life.
Also, Brave is consistently 20-30 points below vanilla Chrome on BrowserBench? Any ideas why?
And finally, and this is pretty egregious, but the 1Password browser extension is a 20-30% (yes) performance hit (on the BrowserBench benchmark) on any Chromium based browser that I use, and on Firefox. What the fuck, AgileBits?
See for yourself: https://browserbench.org/Speedometer2.0/
Chrome basically owns the web outside of Mac though, so perhaps you're using some services that favor it. Or the search bar that sitters is Google's and it's been known to have some Oopsies[1]
[1] https://www.zdnet.com/article/former-mozilla-exec-google-has...
As for the affected websites, Lexis Advance, Westlaw, WSJ, NYT, the Economist, Ars Technica, Wired, Hacker News all display this behaviour. It's a Safari problem.
For whatever it's worth to others, in the past few hours I managed to download Orion and while I've got a very small sample size thus far, it's been basically perfect experience thus far. Really gotta wonder how the 2 trillion dollar company's browser team is getting outgunned by the 2 man team or whatever that Orion has.
I had this. It went away when I stopped using the tab groups.
It's a shame because I _liked_ the tab groups, but I like not being annoyed by a stupid search bar bug more.
Safari: https://i.imgur.com/LcPD5eE.png
Your score is quite the improvement over Safari (15.4) on my late-2019 Intel (i9 2.4) 16" MacBook Pro.
Chrome 99.0.4844.51:
- 1Password + µBlock Origin: 277 ± 2.9
- No extensions: 303 ± 5.1 (9% faster)
Safari 15.3:
- 1Password: 251 ± 2.6
- No extensions: 280.5 ± 2.6 (11% faster)https://open-web-advocacy.org/files/OWA%20-%20Bringing%20Com...
Reddit is its shitshow and I ended up installing Apollo. This is not Safari’s fault.
So if you're using Chrome or Firefox on iOS, the rendering is not handled by Blink or Gecko, respectively, it's handled by WebKit.
Here's both, no plugins, latest versions:
https://user-images.githubusercontent.com/12100/158299113-a0...
Chrome opens and closes slower, resizes slower, opens tabs slower, closes tabs slower, restores a closed tab slower, goes back/forward slower, stutters as it scrolls... and feels non-native in so many ways. Not to mention the constant addition of bloat and privacy invasive features.
Safari is nearly an order of magnitude better IMO on a Mac, it's not even close.
My point still stands about going back a page and arrowing up/down the URL bar to select something and having it swap at the last second. Those behaviours are peculiar to Safari and they're really inexplicable from a user perspective. Whether it's related or not, the mobile version of Safari is even worse - going back a page refreshes 95% of the time, when it shouldn't given the amount of RAM iPhones have had for the past 5+ years.
The Chromium stuttering on M1 Macs is definitely a problem and I wish Google would get to fixing it.
When Apple does it, it’s looked at with derision.
By...who? There's 100 comments in this thread right now and not one is criticizing the new features.
> Web developers are interested in the features that are widely supported. "Being first" helps no one.
which I read as expressing contempt - the very definition of "derisive".
> Chrome is first with a new CSS feature, it’s the greatest thing since sliced bread. When Apple does it, it’s looked at with derision.
So, "new" as in first implementation in a browser.
If that were the case, nobody could use new features unless all three major browser engines supported them at the same time and that’s clearly not happening.
It’s pretty easy to use @supports to check for feature support. CSS and HTML are pretty resilient with code they don’t understand.
Remember Chrome ships things all the time other browsers don’t support but that’s okay for some reason…
You can follow along here
Does that mean <link rel='preload'> finally works on Safari?
https://caniuse.com/?search=prefetch
Thanks for catching my mistake.
Worst browser especially it is impossible to debug in windows.
Yeah, Safari is the worst...
Maybe there's hope that I can then just turn this off on a browser level? I've got gigabit internet at home, and your images popping in on scroll makes it feel like I'm on dial up.
Lazy loading images is at best user hostile bandwidth saving, and it's not even that much in this day and age.
The experience you describe is with JavaScript lazy loaders which don’t have this awareness.
I have Bromite configured with DoH that almost blinds my ISP as well as Tor Browser.
Privacy Browser disables JavaScript by default, with an easy toggle to enable it, which is invaluable for taming many sites with obtrusive scripting.
I use Firefox Focus with the bundled libgecko for general browsing.
If I tried this on a Microsoft platform, I would constantly be advised not to do this.
I wish there was a good WebKit browser for Android, just for diversity.
A real mobile Webkit would make testing for iOS a hell of a lot easier. I'm not planning for buying a mac just to run a browser, we're not living in 2010 anymore. Even Microsoft bothers to provide free VMs for developers to run their browser tests in.
The primary use case is to not load images you may not ever see because you may not scroll that far down the page and they don't appear in the viewport.
Like any feature, it has to be used correctly by the developer… obviously hero images and other images important to the initial user experience shouldn't be lazy loaded.
That is the "bandwith saving" part. It's user hostile because it is another non-JS privacy leak and because it means that you can no longer open a website to read later when you might not have internet access.
> obviously hero images and other images important to the initial user experience
Hero images are typically the most pointless and irrelevant to the user experience. If you want to save bandwidth then push back against this fad.
Where without lazy loading they could normally get up and get a cup of coffee and come back, you are now actively wasting their time as they scroll.
It's good for mobile devices, since you can save on usage caps (which should be illegal, but that's a digression).
It’s horrible UX when you open a bunch of tabs in the background and then when you try to read them, they haven’t loaded properly. Especially if you are on a train or something where your Internet connection is spotty and they could have loaded at the point you opened the tab, but now they cannot.
The main improvement here is that if it is built into the browser instead of implemented individually on each site with JavaScript, there’s a better chance you’ll be able to disable it globally.
Also lazy loading enables the bandwidth that is available to be used on critical path items and not on images further down the page, especially if they’re non-origin images that require the overhead of another TLS handshake + connection, etc.
You don’t get the benefit of HTTP/2 prioritization with non-origin connections.
It can easily be the vast majority of bandwidth spend even on a lightweight site. Add video widgets and bring that closer to 99%. Lazy loading is frequently a "can afford an extra 5 full time engineers" optimization
I find this figure suspect. I work on a site with millions of users whose core service is essentially displaying a stream of images to end users, and our spend on CDN bandwidth is barely into five figures
A small video site might start at 3 Gbit/s, a medium sized one closer to 30. These estimates really are quite conservative depending on the context
Poorly implemented lazy loading of images is probably the culprit here
You might want to consider how lucky you are for a second.
The suffering is over!
Too bad Safari still does not offer this as a toggle on iPadOS. I really hate the fullscreen video players on my iPad. They are mostly unusable with touch. Maybe it can be controlled using an Extension?
There are of course a lot of nice built-in solutions to things, but having a quick-and-easy modal mechanism allows people to have cleaner code for something they're gonna try to do one way or another.
Amusingly there's also a WebP lossless which is a completely different algorithm they just let a random employee invent.
This idea wouldn't work for video due to how computational intensive video encoding are and storage space concern. But may be it would work for image?
Or if we could somehow magically improve the JPEGXL encoder quality by another 20-30%.
Shame, because I really do like Safari.
The bundling of Safari versions with iOS, combined with the draconian policy of "Safari is the only legal rendering engine on iOS", bites me every day as a developer that's working on a mobile site for iDevices.
I know people like to complain about Safari, but:
1. It’s absolutely common to ask developers for a minimal repro case in a bug report.
2. There are four major Safari releases under 15.x.
3. Apple OS upgrades, especially iOS, are as close to total as one could imagine. The overlap between people who buy iPhones and people who go out of their way to turn off OS upgrades is really small.
I want Apple to stop tying (some) Safari releases to OS upgrades, but this honestly feels like you’re tired and it’s been a long day, and you could use a break. Take the night off. Safari will still be imperfect but improving tomorrow, even if it’s not at the pace we’d prefer.
I want Apple to stop restricting third-party browsers on iOS. MacOS Safari has the same WebGL bugs, but our game's Desktop client uses a WebView under our control & versioning that isn't Safari, and so doesn't have the bug.
If iOS had the same capabilities, I wouldn't care at all if Safari introduced bugs, since it wouldn't break our product.
This isn't the first, or second, or third time that Apple has shipped broken stuff in Safari on iOS which broke our product. I've been dealing with this for years, and it's not getting any better. I'm absolutely frustrated about this, but when I spend time honing in patches for Safari regressions & Safari just ships more regressions, it's hard not to be frustrated.
[1] https://twitter.com/jensimmons/status/1491064075987873792
Random rendering glitches/disappearing-reappearing dom elements.
Impossible to debug without Mac and no problems in any other browser.
Seriously frustrating.
Happens on latest Safari on MacOS, too: https://cdn.discordapp.com/attachments/476502698066182179/95...
I'm not sure if the video represents what's going on perfectly, but it appears like maybe it's reading old data from an improperly cleared framebuffer or something?
a side question, how do you make a bug report on Safari? I've found FF and Chrome easy enough, but when I went to look for making one on Safari about a year ago I decided screw it, it seemed hard to find where to start (by googling at any rate)
When people want to get their work done, opening another browser while the original one is being fixed (which might take a couple weeks), for certain applications, is extremely reasonable for business people just trying to get their work done.
This foundation is provided by browsers and is also broken by browsers. If safari's foundation is broken then safari is the one not fulfilling that fundamental promise, not the websites now broken. So yes, don't use a browser if it doesn't work.
Before Opera gave up and became another Chrome reskin, there were plenty of sites that didn't work for me until I set the user agent to match another browser.
https://webkit.org/status/#feature-web-midi
Note that Web Midi isn’t any kind of standard; it’s not even on the standards track. From the specification:
> This document is merely a W3C-internal document. It has no official standing of any kind and does not represent consensus of the W3C Membership.
In about:config, I have dom.webmidi.enabled set to true. I'm using this test page and waiting for the day it starts working for regular version of Firefox.
Neither Safari nor Firefox are going to implement them.
For something to become a standard that something needs two independent implementations. Before that it's just some browser's prototyping stage, no matter how many times Chrome will tell you otherwise.
According to chromestatus, WebMIDI now has positive position from Mozilla and negative position from Safari: https://chromestatus.com/feature/4923613069180928
Just three years ago Firefox's position was also largely negative due to unresolved security issues: https://github.com/mozilla/standards-positions/issues/58 It's possible those issues are now resolved, that's why it's making its way into Firefox. This means that Safari's stance may also change.
Same goes for other hardware APIs: from the point of view of both Safari and Firefox those specs have security and privacy holes the size of Jupiter. Not to mention that the quality of some of these so-called specs is very low. If/When these issues are resolved, we may see them implemented in these browsers, too.
I mean I'm sure they still are, just slightly less now.
But kudos on the gradiant and CSS improvements.
<dialog> is easy to polyfill well: https://github.com/GoogleChrome/dialog-polyfill
This is something that can and has been polyfilled for the moment, but runs into some a11y issues with screen readers and the usual style/compatibility ones that a native implantation won't.