This is like complaining you can't use electricity to fill up a petrol car...
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.
Until Apple fixes the mess they made with ad-blocking and allows full-fat ublock origin to work on Safari again, it could be 100x better than any other browser and it would still be worthless compared to Firefox.
Somebody correct me if I'm wrong but last time I checked I couldn't find any content blocker for MacOS Safari that would block pre-roll Youtube ads whereas uBlock Origin in Chrome, Firefox, etc. does not have this problem.
I want a free solution because that's the standard in the space. I shouldn't have to pay money to make a browser with less features have parity with a better developed one.
Safari content blockers don’t get access to the website. They merely present a list of selectors to block, and Safari does the rest. So the lack of source code access is benign, by design.
Content blockers don't have access to websites, but they themselves need to be "hosted" within a native application, right? And that application can potentially do more than just provide a list of rules to Safari.
I use Wipr too, but it seems like a couple months ago, Google figured out how to get past it since I see shippable ads 50% or more of the time. I used to never see them.
I develop an ad blocker - Magic Lasso Adblock [1] for Safari that flawlessly and completely blocks all ads in YouTube. It works across iPhone, iPad and Mac. So it can be done and the experience works when implemented correctly.
It’s within the testflight app, there’s a share button and you can copy the link. Borrow was an incorrect term, the link is still valid for anyone afaik.
A lot of good (if long-awaited) changes in there, like smooth scrolling. Interesting to see how hard they're pushing the fact that they are the first browser to implement a bunch of features.
Being first is fine so long as you're not last in anything. If you announce that you're the first do to something and you're the only one who hasn't done something else, you're holding back everyone so you can introduce features no one can really use.
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…
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.
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.
I've used it in a container for ages (SlimSocial on F-Droid store). I removed it being listed by my launcher so I have to go through Settings > Apps and scroll that list. It's so annoying to use and get to it that I barely use Facebook anymore.
Apple likes to trot out Facebook as a privacy boogeyman when it comes to defending their App Store business model, but when their business model necessitates that Facebook has invasive native apps, suddenly they're silent.
PWAs would increase security all around compared to native apps, but that might cut into App Store revenue.
> Apple likes to trot out Facebook as a privacy boogeyman when it comes to defending their App Store business model, but when their business model necessitates that Facebook has invasive native apps, suddenly they're silent.
Exactly my point, they'll trot Facebook out as a defense of their App Store model just like they did here. PWAs from the beginning would have prevented Facebook from collecting data for the last decade in the first place, but that's not a solution Apple would allow.
True, a PWA wouldn’t have been able to get the unique device ID, which is (I think) the only technical effect of the App Tracking Transparency toggle added last year. But that toggle also has legal effects that go further [1]. For instance, apps can’t “[display] targeted advertisements in your app based on user data collected from apps and websites owned by other companies”, even that data was correlated with your app session based on, say, account name or email address rather than device IDs. But the only reason Apple is in a position to impose this kind of requirement is that they’re a gatekeeper for iOS apps. With web apps, short of government action, the best you can do ask nicely, and we all know how the Do Not Track header ended up.
> Exactly my point, they'll trot Facebook out as a defense of their App Store model just like they did here
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.
The claim is expected it's just being called out as false basis with explanation of why after your quoted section.
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.
Can I just say “throwing the dishes out with the bathwater” is the best thing I’ve read today? I want you to get the notifications you prefer, I want to not get web notifications, I don’t care to argue over that. I just want to appreciate doing the dishes in anyone’s bath water. That’s darn efficient!
I was following this and it did seem to appear in the beta -- I'm not sure whether it has been removed in the GA version listed here, or if they simply haven't mentioned it since it's perhaps a browser rather than WebKit feature?
... I assume WebKit has had support for this for a long time, since Safari on macOS has long supported push notifications.
> 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].
I thought I read [0] that there will be experimental support for push notifications in 15.4. Perhaps keep any eye on advanced safari settings when it comes out?. At least there appears to be progress, and you may be able test it.
Personally I really hope they don't add this. Imagine how annoying to have to decline a "please turn on notifications" on every news site on your phone (which you're spammed with on desktop).
This is actually the perfect compromise that I haven’t even thought of until you’ve mentioned it. Up until now, I was opposed to webkit push notifications for the same reason as the grandparent comment. Thank you for your comment.
You're welcome! Yeah, I didn't even know that they could segregate it based on whether it was going through the Add to Homescreen option, but learned of it through the article:
> 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.
Unfortunately Apple has crippled PWAs compared to the exact same code running in the browser on multiple occasions. Up until just about a year and a half or so ago you couldn't access a WebRTC stream from a PWA. The main use-case I needed this for was for a barcode scanner (which uses WebRTC under the hood) so my options were "deal with browser chrome" or "repackage into an app", I ended up doing the second (and to be fair that was my ultimate goal) but I would have preferred to skip dealing with that until later (prototyping is still faster on web for me, even with live dev builds on mobile).
AFAIK historically Home Screen web apps were run in a separate runner from the main Safari based on the web view control, and thus limited. There was a time they didn't get native JIT for javascript, either.
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.
A lot of these complaints are about the underlying notification system, which is way, way better on iOS than on Mac, and is already what you get if you have app notifications anyway.
Apple could implement this with a default of "automatically decline all", allowing users to only manually opt-in when they feel the need without ever seeing a prompt.
If you mean html/css prompts rather than actual browser prompts: they already do that.
As the person working on PWA stuff on Discourse I can assure we will be adding push support in iOS as soon as it's ready. It's a shame this is taking so long on iOS devices...
Doesn’t supporting web push notifications involve having worker processes running in the background all the time to poll or keep a socket open for updates? I could see that dragging down battery life if one has notifications for more than just a small handful of PWAs enabled.
Disagreed; they don't. They delegate messaging to the Apple Push Notification service which is a single process that maintains a persistent connection (and receives messages on behalf of apps). Apps only get woken up when a notification actually arrives.
While we don't see updates in this announcement, we may start seeing more because they're getting so much antitrust pressure [0]. Handicapping PWA support by not supporting push notifications works strongly against any arguments they would want to make about there being viable alternatives to listing in the app store.
I'm grateful I don't get random popovers asking me whether or not I would approve a popup asking me to grant permissions for push notifications (because the scripts exit early on mobile safari)
I don't feel overwhelmed by popups asking me to grant permissions for push notifications. But I'm glad that both sites where I care for them, can push them.
I mean, yeah, with a thing popping up on my screen to ask me for it. Which is fine if I, say, install it as an app (eg PWA or whatever), but super annoying on websites I’m visiting for the first time.
It would mean a great deal to all sorts of web apps!
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!
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.
On that note, TIL about screen reader issues related to dialogs in general, including this built-in. Seems like the question is primarily around how to update the focus target from the "invoking element" to the dialog's content in a reader-friendly way. There's a linked post from the MDN docs with more detail https://www.scottohara.me/blog/2019/03/05/open-dialog.html#i.... They actually still recommend a custom implementation that's considered more robust when used with screen readers: https://github.com/KittyGiraudel/a11y-dialog. I'm glad there's a callout on the MDN docs as I would have assumed this dialog element is screen reader clean. Focus management is always a tough thing regardless.
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.
Webkit is not committed to fully implementing the HTML Living Standard, or more precisely, they are committed to killing off the parts they don't like by declining to implement them. They point-blank refuse to implement Customized Built-in Elements, for example, and in such (unusually, for the context) vehement, uncompromising, and unconstructive language¹ that I can only surmise some Apple apparatchik's fragile ego would be irreparably shattered by even contemplating an amendment of this position.
Thanks to such attitudes, Safari remains the "new IE", the problem browser for which developers must find workarounds.
I glanced at the linked issue and I see demands for disregarding the standard to accommodate a non-standard API. Is that what you’re asking for? Or are you on the side of implementing the living standard as it evolves? If there’s another position I’m missing feel free to fill in the blank.
That is a very heavily commented ticket (600+ comments) so it’s hard to assess all the alternative positions.
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.
> 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?
HTML Imports were superseded whilst still a draft.
Members of a standards body are accountable for their actions. Endorsing a standard, then undermining it, is a gross dereliction of duty. These omissions have a direct impact, and you can draw a straight line from Apple’s overwhelming institutional arrogance to Safari being the “new IE”.
> Members of a standards body are accountable for their actions.
Yes, yes they are. This also means that none of the browser implementors should be on the steering committee by your criteria.
> Endorsing a standard, then undermining it
Let's see about that endorsement and "undermining":
--- start quote ---
Now I'm going to re-iterate that Apple objects to extending subclasses of HTMLElement using is= as currently spec'ed for various reasons we've stated in the past and this feature won't be supported in WebKit.
...
I'll note that we've vocally and repeatedly objected to having is=, and in fact, stated publicly that we won't implement this feature, but somehow the WG kept it in the spec. I wouldn't call that a consensus. We extremely reluctantly agreed to keep it in the spec until it gets removed at risk later.
...
we're against subclassing subclasses of HTMLElement (e.g. HTMLInputElement, etc...) for various reasons, so WebKit isn't going to support this feature anyway. Extension of builtin elements are much better served with mixins.
The thing is, Apple has been objecting to this feature from the get go, and the only reason it remains in the spec is because Google kept objecting to it being removed from the spec.
The fact of matter is, we only agreed to keep it in the spec to wait until the feature becomes at-risk at CR stage so that it can be removed.
This extended excusing of bad behaviour doesn’t wash. You can’t reject part of a standard, when you’re one of the stewards of it. Either you’re committed, or you’re not. Like cabinet government, debates prior to decision don’t factor into your necessary commitment to the decision once it is made. A lower moral standard is only available for those who don’t claim to be the high priests.
Trivialising the issue with whataboutism doesn’t make Apple any less culpable. Sure, shit sticks to other vendors too. Google often behave appallingly, but this’ll be my first and last mention of them in this thread, and I feel just fine about that having given them plenty of stick in the past. My comment was and remains about WebKit.
HTML Imports were superb and amazing. No idea why all modularisation needs to be forced to be Javascript. Even a hello-world web component is forced to be in JS.
It's utterly disgusting because you just know that good proposals are nixed behind the scenes because Google doesn't want anyone disabling JS - their ads would suffer. More JS == GOOD, more declarative stuff in the spirit of HTML == BAD.
I really wish Apple would go their own way and propose and implement alternatives. Better than taking Google's highway. I would prefer a fragmented ecosystem over the Tyranny Of Chrome that wants to destroy your privacy and the spirit of the world wide web.
To quote Ryosuke Niwa, one of the main developers in WebKit [1]:
> Many years ago, Apple's WebKit team argued that we should have declarative way to define custom elements without scripts but we lost to the aggressive push by Google to get things shipped and iterate on it later ASAP.
This is whining about process and not getting your way, which just confirms my earlier hypothesis about fragile egos.
Apple are complaining here about their own failure to be convincing. They’ve then had the better part of a decade to find a better approach, and produced nothing concrete. Compounding one failure with another doesn’t improve their position.
This isn’t David v Goliath; WHATWG has four members, and none of them are underdogs. None of the participants here deserve even a shred of sympathy.
> Safari remains the "new IE", the problem browser for which developers must find workarounds.
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?
Sure, simple websites mostly work in Safari. But we're in 2022, and indeed a lot of companies develop web apps, and not simple websites like 20 years ago.
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.
It's in the vein of your statements, and it takes too much time to explain why this is wrong. And this has been said many times before by many people far more eloquent and knowledgable than I. Yet this sentiment persists (even if it's driven by emotion on the one hand and relentless Chrome propaganda on the other).
That's not in contradiction with what I said. I have nothing against web apps and I'm not arguing against their success. But they don't make the web irrelevant, they are just something different, just historically built on top of the web.
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.
As a long time web dev who primarily uses Safari for development, I find myself constantly looking for workarounds for Chrome.
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.
That's definitely not representative of the general sentiment. As far as I'm concerned, probably around 95% of my debugging time is spent on Safari. Stuff usually works like a charm in Chrome or Firefox. Safari is a gigantic pain due to its plethora of bugs (and new ones appearing with each release) and missing features preventing you to easily work around them.
Web application developers will rightly question the claim that Safari has surpassed Chrome in anything in 2022. With "Safari Technology Preview" and the test suite that this site has chosen to group into "Experimental," you'll see FF: 74, Safari: 73, Chrome: 72.
With "stable" and actually-consumed versions of browsers (a more important goal for "interop"), you'll see:
Interop is meant to guide future development. I think there's a reason the default values are based on the experimental versions instead of stable releases
Just last year the same people at Chrome who advocating for removing of alert/confirm we're advocating for removal of <dialog> because it was inadequate.
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.
Most workplaces, upon seeing that you’ve done this, will say “look, you can reinstall the corporate profile, or you can hand back the computer, or you can be fired.” (And if they catch you doing any circumvention to prevent them from finding out, then your options are likely to be “you can be fired”)
What use do you have for that in a web application?
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.
I recently used a lookbehind to replace \n by \r\n only if it’s not already preceded by \r. It was in a VSCode extension, because the output channel of the testing workbench stupidly requires \r\n, otherwise it doesn’t go to the beginning of the line.
I could have done it without a lookbehind but occasions to use it are quite rare to me :)
> New support for BroadcastChannel allows tabs, windows, iframes, and Workers from an origin to send messages to each other. This enables experiences like syncing login state for a site across multiple tabs.
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 think this means SharedWorkers are not too far behind. Pretty sure I saw a issue tracker indicating maybe SharedWorkers had been restored in a nightly build?
Yeah I saw that tweet. +1 for Safari, but we’re still -24.
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.
I really wish Safari would go away and Mozilla would switch to a full featured Chromium with everything enabled (But user-toggle-able).
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.
My life would be a lot different if I had the skills for the google team or any of the FAANG teams.
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.
With so many new features being added to browsers lately it is easy to forget, that not all browsers on old devices are updated, be it older iPad or even laptop with ChromeOS. Dear web developers, please don't forget to add fallbacks or polyfills for older devices.
That's the risk you take by buying iPhone or ChromeOS: you're buying into a platform where you don't have the option to find alternatives for "core" system functionality.
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.
Not on all models (especially not on the older ones), and even then it's unnecessarily complicated by design. There are workarounds that come with a performance impact, but most Chromebooks aren't exactly powerful machines.
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.
Finally Mozilla does something sane! This is really great news, and I could see this being a pretty big thing or even a major way of doing web enabled IoT.
I've been regularly checking that page, delighted with every step of progress as WebMIDI gets implemented in Firefox.
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.
In Firefox 98.0, it actually works but is well-hidden. You not only have to turn on dom.webmidi.enabled in about:config as you've already done, but also need to manually add 'Access MIDI devices' and 'Access MIDI devices with SysEx support' permissions for the page in Tools -> Page Info before reloading, as otherwise it silently fails instead of prompting for confirmation. Hot-plugging interfaces after the browser is launched also doesn't seem to work yet.
No WebUSB either (Or ever I guess), I know some HN people might not be a fan of it but personally I think it has huge potential to cut down on engineering waste. No need to build custom apps for every platform to just interface with a hardware device and also because it's a shared spec makes hardware devices hackable and alternative clients easy to create so devices can live on if their creators companies go under.
Firefox is implementing WebMidi so I don't think this idea people are passing around that these are "not real standards" so won't be implemented holds much water.
I was responding to WebUSB, and tacked a few other hardware APIs there. Both Firefox and Safari view them as harmful in their current form. They are not really on a standards track for now, they are "Draft Community Reports" or somesuch.
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.
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.
> WebKit added support for lazy-loading images with the loading attribute on the <img> element, providing web developers with an easy way to instruct the browser to defer loading certain images until the user scrolls near them
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.
> Lazy loading images is at best user hostile bandwidth saving
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
> 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
I picked 5 at random, but I guess it really depends on where you are. Assuming 5 was the real number, that's only $28k/month bandwidth spend given the average SWE salary in the UK (£38,561 going by google), including 33% for tax and non-salary costs. That's about 327 TB worth of undiscounted AWS bandwidth, or roughly a site averaging 993 Mbit/s.
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
Chrome has the same feature and lets you disable it. That's probably the best compromise. You have amazing Internet. For the typical user, heavy image loading slows them down, and they're also less comfortable diving into browser settings.
In my experience it's more user hostile the worse your connection, because they have to sit and watch the images load for an even longer amount of time than I do, whereas it could have kept loading for them ahead of time.
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.
If the person is viewing a gallery website, perhaps, but most websites are centered around textual content, which would be available much faster with lazy loading of images, thus the user on poor connection would actually get the _useful_ part of a website much faster.
Honestly, it's more so. Greedy loading means that on a slower connection images will load before you scroll to them. If you're lazy loading, the request doesn't kick in until later, so you'll be waiting for images to load.
It's good for mobile devices, since you can save on usage caps (which should be illegal, but that's a digression).
People forget that latency impacts web performance and not just bandwidth.
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’s even more user hostile when your connection is not great.
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.
Lazy loading images is at best user hostile bandwidth saving
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.
> 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.
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.
The idea is that the browser, which is aware of your bandwidth, will disable this for you. But for a user on a limited bandwidth connection it’ll implement it. In other words the lazy attribute is a suggestion, not an instruction.
The experience you describe is with JavaScript lazy loaders which don’t have this awareness.
I agree, I'm quite surprised there's no Webkit browser on Android just yet. Though, based on my experience with Webkit on Linux, the Android version of Webkit would probably be leagues behind Safari.
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.
Unfortunately if you want to rank these days you have to implement these kind of things, or Google marks you site down as having poor performance. At least with a standard <img> attribute there is now a chance for a simple browser setting to turn the behaviour on/off/auto depending on connection type/etc.. unlike all of the various javascript solutions.
I don't use it just for my users, I use it for my sites which are extremely image heavy and I don't want to load dozens of images that the user might never scroll to.
> Developers can now enable Navigation Preload in ServiceWorker to improve load performance and avoid ServiceWorker startup delays that block network requests
Does that mean <link rel='preload'> finally works on Safari?
Navigation Preload is a different feature that is specific to Service Workers. `<link rel=preload>` has been supported in Safari for a while, since 11.x.
Not true in most cases. Usually popups have use position:fixed so they can be “easily” targeted. I remember seeing some extension that disabled position:fixed across the board (I assume it had terrible perf though)
> Apps on iOS, iPadOS, and macOS can now control allowing or preventing web content from using the Fullscreen API.
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?
Really looking forward to start using cascade layers. Hopefully it'll encourage the community to work closer to pure CSS and leave behind some of the madness out there like CSS-in-JS or Svelte's scoped styles.
I immediately looked for haptic feedback support but alas it's not there. I get that it could be abused so I'd want it as an opt-in feature. It's really useful for soft keyboards (of all kinds).
310 comments
[ 4.6 ms ] story [ 365 ms ] threadBut 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.
Shame, because I really do like Safari.
[1] https://www.magiclasso.co/
https://browser.kagi.com
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.
> 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.
> 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".
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…
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”
https://www.fbpurity.com/
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.
... I assume WebKit has had support for this for a long time, since Safari on macOS has long supported push notifications.
https://firt.dev/ios-15.4b
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...
[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.
> 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.
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.
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.
If you mean html/css prompts rather than actual browser prompts: they already do that.
[0] https://www.forbes.com/sites/siladityaray/2021/08/27/apple-a...
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!
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.
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.
https://wpt.fyi/interop-2022
That is, there hasn’t been a new version of Safari Technology Preview, which is what the experimental numbers are based on.
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…
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
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?
Members of a standards body are accountable for their actions. Endorsing a standard, then undermining it, is a gross dereliction of duty. These omissions have a direct impact, and you can draw a straight line from Apple’s overwhelming institutional arrogance to Safari being the “new IE”.
Yes, yes they are. This also means that none of the browser implementors should be on the steering committee by your criteria.
> Endorsing a standard, then undermining it
Let's see about that endorsement and "undermining":
--- start quote ---
Now I'm going to re-iterate that Apple objects to extending subclasses of HTMLElement using is= as currently spec'ed for various reasons we've stated in the past and this feature won't be supported in WebKit.
...
I'll note that we've vocally and repeatedly objected to having is=, and in fact, stated publicly that we won't implement this feature, but somehow the WG kept it in the spec. I wouldn't call that a consensus. We extremely reluctantly agreed to keep it in the spec until it gets removed at risk later.
...
we're against subclassing subclasses of HTMLElement (e.g. HTMLInputElement, etc...) for various reasons, so WebKit isn't going to support this feature anyway. Extension of builtin elements are much better served with mixins.
...
And this entire comment: https://github.com/WICG/webcomponents/issues/509#issuecommen...
--- end quote ---
So did Safari endorse Web Components? Yes. And they still do. See, for example, Template Instantiation Proposal (among many other things): https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
Did Safari ever support `is=`? No.
Let's see their endorsement again:
--- start quote ---
The thing is, Apple has been objecting to this feature from the get go, and the only reason it remains in the spec is because Google kept objecting to it being removed from the spec.
The fact of matter is, we only agreed to keep it in the spec to wait until the feature becomes at-risk at CR stage so that it can be removed.
--- end quote ---
I would also recommend you read this comment on the whole process and "obligation to implement" and other things (it's not from Apple): https://github.com/WICG/webcomponents/issues/509#issuecommen...
> and you can draw a straight line from Apple’s overwhelming institutional arrogance to Safari being the “new IE”.
There's definitely a PR manager in Chrome who gets a bonus every time this line is repeated. See breaking the web forward: https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
Trivialising the issue with whataboutism doesn’t make Apple any less culpable. Sure, shit sticks to other vendors too. Google often behave appallingly, but this’ll be my first and last mention of them in this thread, and I feel just fine about that having given them plenty of stick in the past. My comment was and remains about WebKit.
It's utterly disgusting because you just know that good proposals are nixed behind the scenes because Google doesn't want anyone disabling JS - their ads would suffer. More JS == GOOD, more declarative stuff in the spirit of HTML == BAD.
I really wish Apple would go their own way and propose and implement alternatives. Better than taking Google's highway. I would prefer a fragmented ecosystem over the Tyranny Of Chrome that wants to destroy your privacy and the spirit of the world wide web.
> Many years ago, Apple's WebKit team argued that we should have declarative way to define custom elements without scripts but we lost to the aggressive push by Google to get things shipped and iterate on it later ASAP.
[1] https://twitter.com/rniwa_dev/status/1352322006448947203
Apple are complaining here about their own failure to be convincing. They’ve then had the better part of a decade to find a better approach, and produced nothing concrete. Compounding one failure with another doesn’t improve their position.
This isn’t David v Goliath; WHATWG has four members, and none of them are underdogs. None of the participants here deserve even a shred of sympathy.
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.
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.
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.
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.
With "stable" and actually-consumed versions of browsers (a more important goal for "interop"), you'll see:
- FF: 74
- Chrome: 66
- Safari: 50
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.
https://webkit.org/downloads/
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 :)
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.
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.
No. Chrome is perpetually in Fire and Motion.
Chrome is not the standard, https://v4.chriskrycho.com/2017/chrome-is-not-the-standard.h...
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.
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.
https://versioduo.com/webmidi-test/
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.
— https://webaudio.github.io/web-midi-api/
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.
The suffering is over!
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.
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
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).
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’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.
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.
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.
You might want to consider how lucky you are for a second.
Poorly implemented lazy loading of images is probably the culprit here
Does that mean <link rel='preload'> finally works on Safari?
https://caniuse.com/?search=prefetch
Thanks for catching my mistake.
Might as well get started on those uBlock filters!
[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
You can follow along here
https://bugs.webkit.org/show_bug.cgi?id=222382
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?