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.
> 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.
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.
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).
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.
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”.
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.
> 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.
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.
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.
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'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.
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...
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.
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.
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.
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.
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.
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 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.
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.
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.
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'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.
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.
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)
> 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.
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 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?
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.
I'm happy to contribute two new features as part of my WebKit internship: the ic unit (as mentioned in the changelog), and CSS Motion Path, which I'm honestly surprised is not mentioned.
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 :)
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.
Credit where credit is due: this is a rarely good release.
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.
> 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.
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.
...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.
Is Apple going to do anything about Safari (on my 2021 16" M1 Pro) hitting 200 points in BrowserBench, while Chrome hits 299? Sure, Safari battery life is great, but the browser is slow, buggy (refreshes the page when I back a page half the time; can't speed up videos without audio distortion; typing into the search bar is laggy and I on a daily basis arrow down to select a previously used URL, hit enter, and then find that Safari moved my selection up or down, almost like it had to sync or something).
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?
I have none of those problems on my M1 MacBook Air using Safari. I know no clue what extensions you're using or voxel based games you're running in browser but safari opens, closes, resizes, and runs websites in a far nicer way and cleaner way. I've never seen a search box stutter.
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]
1Password, Wipr, Dark Reader, StopTheMadness. That's about it.
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.
> typing into the search bar is laggy and I on a daily basis arrow down to select a previously used URL, hit enter, and then find that Safari moved my selection up or down
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 on my iPhone is basically unusable. Refreshes the page constantly; swipe back a page and it refreshes; scroll down long enough and it refreshes. Then there's Reddit - crashes constantly, literally will not load comments. It does this with and without extensions.
Sounds like you’re on an old phone? I did have RAM issues on the 11 Pro that unloaded every app as soon as I opened the camera, but otherwise tabs did not unload that often.
Reddit is its shitshow and I ended up installing Apollo. This is not Safari’s fault.
Personally I don't use Safari because among my Apple devices there is also a Windows desktop unit and I do enjoy myself browser sync across devices. So Firefox it is... Otherwise I would have switched to Safari when extensions finally became a thing.
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.
It's definitely down in a large part to plug-ins. Things like Dark Reader I can understand, but I have no idea why 1Password would cause a 30% performance drop on a site that I don't even have a PW for.
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.
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…
> 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.
I wrote a PWA for my personal use that appears to be broken now that I upgraded to 15.4. I use it for time tracking, so I think it has something to do with Dates or Inputs of type datetime. Haven't had a chance to debug it yet.
WebKit broke my org's <canvas>-based product with 15.x release, have to disable GPU Acceleration in order to prevent full page refreshes while drawing anything complicated after about 20 seconds and its consistent to reproduce. Checkout Apple Dev forum or any HTML5 Game Engine Disco/Board/Tracker
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.
> 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.
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.
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.
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.
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).
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.
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.
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.
> 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
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.
Appreciate the work the WebKit team is doing, but would love to see more support for WKWebView devs. The WKPreference updates are nice, but such a small step. As a browser developer targeting iOS (where one is forced to use WKWebView), it is shocking how many hacks are required to build table stakes features on top of WKWebView. Of course, I can imagine the Safari team would have little motivation to help in this regard since it is about enabling competition.
I was just in despair this last weekend when I discovered that vh decreases when the onscreen keyboard shows up and thus reflows my page where some elements have max-height: Xvh. I'm glad this is being addressed with lvh!
> 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?
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.
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).
Been waiting for this for so long. Especially the BroadcastChanel feature since there is currently no way for PWAs installed twice on the Home Screen to “share” data between them. Hope that BC fixes that
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”)
It was just the other day I am thinking, may be all photos saved from the web should either be JPEG ( direct download from the page ) or it would be saved as lossless PNG. We now end up adding AVIF, WebP, possibly JPEGXL, the upcoming WebP2, and what else? I am not entirely sure more format is a good idea.
I thinking more in the line of an image codec that gets constantly updated with browser. And only release it as a standard when it is good enough. So you can iterate and not be bounded by the spec. The server / CDN will serve image that fit that browser requirement, and fall back to jpeg as baseline.
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%.
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.
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.
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 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.
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.
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 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.
Aaaand they introduced WebGL bugs that broke our product, and iPhone users will experience these bugs until we can hack a workaround in, or until Apple acknowledges a bug report (that I have to make a minimal test case for and report, and haven't narrowed down yet), patches the issue in Safari, and decides if it's important enough to release as a 15.4.1 (which they probably won't, which means I'm stuck finding a workaround) - or if it comes out in iOS 16, then a good chunk of our users will never get the fix - so I'm stuck finding a workaround, still.
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.
> decides if it's important enough to release as a 15.4.1 (which they probably won't, which means I'm stuck finding a workaround) - or if it comes out in iOS 16, then a good chunk of our users will never get the fix
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.
1. I absolutely agree, and will be making one to get this bug fixed.
2. All of which have different bugs :^)
3. My product's usage data disagrees. We've got plenty of users on old iOS versions - a really big chunk on iOS 14, for example.
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.
Yep I get that it’s frustrating. I realize in hindsight my comment about being tired might have come off dismissive, but I mean sincerely that I recognize this is an exhausting thing to deal with, and I hope you get the rest and whatever care you need to keep going. Take care.
"you're holding it wrong" said as "you're too tired". OP's tiredness has nothing at all to do with Apple's abusive policy of forcing Safari on IOS. That's the whole entire problem, not OP not getting enough sleep.
My comment did have some clarifying points, but my observation that they may be tired wasn’t a dismissal or rejection of anything, it was just empathy. I’ve come back to respond to this several times and walked away confused each time, because I sincerely recognized that dealing with broken technology takes a toll, and I was surprised by this being interpreted as less sincere. But I did re-read my comment and I see how that could be misread along with those clarifying points.
It could be an ANGLE change responsible. I know Apple's been working on the Metal rendering backend. Maybe something in that is breaking for you.
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)
Our app uses an embedded WebView. An alternative rendering engine would mean we could pin a specific rendering engine version in our app, and only update it for everyone after we work out any kinks with a new version.
The current policies mean that we have zero control over Apple shipping new bugs in under our users' feet.
Sometimes browsers ship bugs of the "this API just does not work anymore" variety.
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.
that sounds like a good short term fix. I guess I was thinking about bigger things like stadia.google.com only working on Chrome browsers. It all seems arbitrary
> The web is built on the foundation I can use any browser.
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.
"Best viewed in IE" was the norm for years and years, supporting only the major browsers has pretty much always been the case.
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.
Unfortunately, Apple have a policy that the inbuilt webkit is the only browser engine that is allowed to be used on an iOS device. The iOS Chrome, Firefox, & Edge apps are just thin wrappers around the same Safari engine included in iOS.
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.
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.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...