[HN Gopher] New WebKit features in Safari 15.4
___________________________________________________________________
New WebKit features in Safari 15.4
Author : ezfe
Score : 146 points
Date : 2022-03-14 19:12 UTC (3 hours ago)
(HTM) web link (webkit.org)
(TXT) w3m dump (webkit.org)
| [deleted]
| traspler wrote:
| > 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?
| SippinLean wrote:
| butz wrote:
| 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.
| noja wrote:
| Web MIDI? Still surprised that's missing on Apple.
| alwillis wrote:
| I believe Apple and Mozilla's position is it can't be done in a
| privacy preserving way as currently specified.
| seumars wrote:
| 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.
| bobbylarrybobby wrote:
| 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.
| alwillis wrote:
| If you go back, you'll see this highlighted by Apple when
| they're first, which happens more often than the prevailing
| narrative would suggest.
| andybak wrote:
| Web developers are interested in the features that are widely
| supported. "Being first" helps no one.
| doctor_eval wrote:
| Unless you're Chrome, in which case it's really great. /s
| alwillis wrote:
| So true. When 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.
| Yaina wrote:
| Wohoo to :focus-visible support.
|
| The suffering is over!
| jimkleiber wrote:
| Edit: removing the snark/sarcasm I put into it.
|
| 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.
| tekacs wrote:
| 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.
|
| https://firt.dev/ios-15.4b
| hwers wrote:
| 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).
| jimkleiber wrote:
| That would annoy me, too. Maybe they could have it only work
| for when you Add to Homescreen as a progressive web app, then
| it would be more opt-in.
| filoleg wrote:
| 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.
| jimkleiber wrote:
| 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.
| doctor_eval wrote:
| 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.
|
| [0] eg,
| https://www.macworld.com/article/610673/ios-15-4-safari-push...
| alwillis wrote:
| It's in there but but not enabled by default, meaning it's
| still in beta.
|
| It'll probably be officially announced at Apple's World Wide
| Developers Conference in June.
| Someone1234 wrote:
| I want it so I can uninstall Facebook Messager.
|
| 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.
| js2 wrote:
| I interact with FB messages solely through
| mbasic.facebook.com, even on my phone. It's painful enough to
| keep me off the site, a benefit.
| jimkleiber wrote:
| Whoa I didn't know that this existed, thank you for sharing
| it.
| CharlesW wrote:
| A nice/useful bulleted summary thread by Apple's Jen Simmons:
| https://twitter.com/jensimmons/status/1503454398487408640?s=...
| teekert wrote:
| Nice list but arg that Twitter... HNers complain when sites
| break the back button, but Twitter breaks back scrolling!
| endemic wrote:
| What's the best way to access newer features in Safari if one's
| work computer is locked to the previous version of macOS?
| ezfe wrote:
| Safari 15 (including this release) is compatible with Catalina
| and Big Sur, you don't need to upgrade macOS releases.
| gpmcadam wrote:
| Not a lawyer etc. but in my experience? Remove the corporate
| build and install what you want. Carry an Ethernet adapter.
| Uehreka wrote:
| 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")
| r00fus wrote:
| Get the developer preview of Webkit if you can download apps
| given your locked down profile.
|
| https://webkit.org/downloads/
| fabiospampinato wrote:
| Here I am still waiting for ES2018 regex look-behinds to be
| implemented. The folks working on the regex engine must have
| jumped ship or something.
| tgv wrote:
| 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.
| olliej wrote:
| look behind assertions can be super useful - obviously you
| can workaround the lack of them, but sometimes simply having
| them there makes life easier.
|
| OTOH get look behind perf to not be horrific is challenging
| brrrrrm wrote:
| dang, still no SIMD for WebAssembly. Chrome and Firefox are
| meanwhile hitting 45gflops (85% of peak) on my M1 Air. Safari
| only gets to 12.5gflops
| dan_g__ wrote:
| donatj wrote:
| > 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.
| ezfe wrote:
| If it's implemented properly, and your internet is actually
| that fast, you won't actually see them loading.
| johncolanduoni wrote:
| If you don't have gigabit internet (i.e. most people), then
| it's not so user hostile.
| donatj wrote:
| 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.
| redwall_hp wrote:
| 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).
| alwillis wrote:
| _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.
| koolaidman wrote:
| Whenever I open an article I just hold the spacebar until the
| full article and all images have loaded, then scroll back up
| dmw_ng wrote:
| > 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
| donatj wrote:
| > 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
| HWR_14 wrote:
| I suspect he was talking about the cost, not the benefit
| 1123581321 wrote:
| 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.
| tiffanyh wrote:
| > 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?
| nikodunk wrote:
| Now all major browsers support the <dialog> element without
| polyfill. Yay!
|
| https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
| culi wrote:
| And just like that, Safari has surpassed Chrome in interop 2022
|
| https://wpt.fyi/interop-2022
| _-david-_ wrote:
| Click stable. Safari is nowhere close.
| alwillis wrote:
| The experimental numbers haven't changed since Interop 2022
| was announced.
|
| That is, there hasn't been a new version of Safari Technology
| Preview, which is what the experimental numbers are based on.
| phantomread wrote:
| 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.
| burtonator wrote:
| > 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.
| imbnwa wrote:
| Wake me when they finally fix the GPU acceleration bug breaking
| <canvas>
| stimpson_j_cat wrote:
| > added support for the <dialog> element
|
| Might as well get started on those uBlock filters!
| dialog[class*="newsletter" i] dialog[id*="newsletter" i]
| dialog[class*="social" i] dialog[id*="social" i]
| dialog[id*="mailchimp" i]
| MBCook wrote:
| Great to see Safari add lazy loading for images! I've been hoping
| for that one, I wasn't aware it was in the works.
| yohannparis wrote:
| Funny how the <dialog> test button does not work on Safari 15.3,
| if it's not backward compatible, it might not be worth
| implementing.
|
| But kudos on the gradiant and CSS improvements.
| crooked-v wrote:
| It seems fairly straightforward functionality to polyfill,
| though.
| silvestrov wrote:
| This does not make sense. Of course new functionality won't
| work on old browsers.
|
| <dialog> is easy to polyfill well:
| https://github.com/GoogleChrome/dialog-polyfill
| chadlavi wrote:
| They're literally announcing that they are adding support for
| it as of 15.4. None of the other things mentioned here will
| work on 15.3 either.
| selectodude wrote:
| 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.
|
| Shame, because I really do like Safari.
| lotsofpulp wrote:
| Are there any comparisons of where content blockers fail and
| ublock origin is better for a casual user?
| nathanasmith wrote:
| 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.
| knolan wrote:
| Probably the best use for a Touch Bar is scrubbing through
| Youtube ads.
| olliej wrote:
| 1Blocker works for me and has good support
| gilgoomesh wrote:
| Vinegar
| ezfe wrote:
| Wipr blocks them for me
| smoldesu wrote:
| Right, for $2 and no access to the source code.
| iknowstuff wrote:
| 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.
| olliej wrote:
| Ah, so you mean you want a free solution, because why
| should the devs of an extension that you obviously value
| earn anything from their work?
| endisneigh wrote:
| Well that's why they're adblocking to begin with - to
| prevent monetization
| _jal wrote:
| Speaking only for me, I'm OK with paying, but trusting
| browser extensions, as they currently exist, is hard.
| ruohola wrote:
| Do you know how Safari content blockers are implemented?
| They by design cannot do much malicious stuff.
| lotsofpulp wrote:
| 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.
| freediver wrote:
| This is one of the main reasons we built Orion browser. Native
| app, with the same rendering engine and with native extensions
| support.
|
| https://browser.kagi.com
| kruxigt wrote:
| daypay wrote:
| Any invites that you could share without having to wait 3
| weeks for the next round to go out?
| [deleted]
| olliej wrote:
| I use 1Blocker and have no issues with ads, so I'm unsure what
| you're after?
| tgv wrote:
| Try Firefox on iOS. It's webkit, but not bad.
| ezfe wrote:
| I use Wipr and it doesn't seem to have any trouble keeping my
| viewing experience ad free, including on Youtube
___________________________________________________________________
(page generated 2022-03-14 23:00 UTC)