[HN Gopher] New WebKit Features in Safari 15.5
___________________________________________________________________
New WebKit Features in Safari 15.5
Author : feross
Score : 57 points
Date : 2022-05-16 17:48 UTC (5 hours ago)
(HTM) web link (webkit.org)
(TXT) w3m dump (webkit.org)
| dmix wrote:
| `inert` sounds like something that could be abused, similar to
| how websites (annoyingly) try to block you from easily right-
| click saving photos.
| evan_ wrote:
| `inert` doesn't let you do anything you couldn't do before, it
| just does it with one attribute instead of a half-dozen
| attributes and CSS rules that need to be applied to the element
| and its children.
|
| You can defeat right-click save-as about ten different ways
| already so that ship has sailed. And all of those can be
| defeated using the Application tab in the Chrome dev tools or
| mitmproxy etc.
| teg4n_ wrote:
| It's desperately needed to implement current patterns like
| model dialogs in an accessible way. It doesn't do anything
| JavaScript can't already do so I don't think it's any worse for
| abuse.
| etchalon wrote:
| It seems like Apple is accelerating WebKit/Safari changes.
| agust wrote:
| They have accelerated and started hiring massively around
| October last year, that is when several regulators started
| investigating the browser engine ban on iOS (the CMA in the UK
| first).
| jinder wrote:
| Correct - after years of deliberately hobbling Safari so you
| couldn't build quality app experiences, they suddenly start
| releasing lots of useful improvement just as regulators are
| sniffing around.
| [deleted]
| scarface74 wrote:
| I keep seeing this conspiracy. It came out during the epic
| trial that the vast majority of revenue from the App Store
| comes from pay to win games. Apple isn't making money off
| of apps that could be a web apps.
| SemanticStrengh wrote:
| any links? (on the hirings)
| jensimmons wrote:
| https://jobs.apple.com/en-
| us/search?search=WebKit&sort=relev...
| SemanticStrengh wrote:
| Those are open jobs which is great to see. Is there a way
| to see the existing number of employees working on
| webkit?
| SemanticStrengh wrote:
| it was an abandonware until last year
| tiffanyh wrote:
| Still waiting for Apple to enable PREFETCH
|
| https://caniuse.com/link-rel-prefetch
|
| It's been there since Safari v13.1 but disabled by default.
|
| (PreFetch is what allows https://instant.page to load assets
| super fast.)
| webmobdev wrote:
| And also extensively used for privacy invasive tracking (1)
| there is no same-origin restriction for link prefetching and
| (2) it allow cookies to be planted from tracking servers. (
| https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe...
| ).
| tiffanyh wrote:
| I thought CSP mitigate this risk.
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Headers/Co...
| lazyjeff wrote:
| While we're making wishlists for Safari, the one I think would
| have the most real world impact is AV1 support, to have a modern
| royalty-free codec across all browsers if Safari adds it. Safari
| is the last holdout. Considering the large proportion of internet
| usage is to transfer video, the savings in storage and
| transmission would be non-trivial.
| babypuncher wrote:
| I do not expect this to happen until Apple starts including a
| hardware decoder in their silicon.
| aluminum96 wrote:
| Apple is very close with the media entities that receive
| royalties from MPEG, h.264, etc, so I wouldn't hold your
| breath.
| galad87 wrote:
| Until there are enough devices with an av1 hardware decoder,
| any storage and transmission saving is lost to the higher
| energy usage and worse battery life for the end user.
| lazyjeff wrote:
| My phone already has av1 hardware decoding (pixel 6). But
| anyway it's a chicken/egg problem, where the broader hardware
| decoding will come once browser support is there. The long-
| term impacts are more significant.
|
| Also, energy use worldwide might decline if fewer datacenters
| are needed to store/transmit videos. Kind of hard to measure
| and compare against enduser devices, but it's another factor
| to consider.
| galad87 wrote:
| Apple makes both its browser and its hardware, so it's not
| really a chicken/egg problem for them. But they are a
| member of Alliance for Open Media, so maybe this WWDC or
| next they will announce something.
| SemanticStrengh wrote:
| webkit leads the dance for once, with their amazing h265
| support
| leeoniya wrote:
| > Fixed scrolling background-attachment: fixed
|
| oh, joy! only took 8+ years:
|
| https://stackoverflow.com/questions/23236158/how-to-replicat...
| [deleted]
| no_way wrote:
| I am still insanely upset that there are a lot of years spanning
| bugs which aren't fixed in Safari or even acknowledged in their
| bug tracker, but the situation is getting a lot better with the
| release frequency and new features so at least there is hope for
| things to get better from here.
| [deleted]
| phillipseamore wrote:
| Still waiting for MSE and fullscreen API support in iOS Safari
| for better media support without having to roll out an app. Both
| have been available on iPadOS for a few years now.
| JanSt wrote:
| I keep hoping for the bluetooth api to be added at some point.
| Still unlikely unfortunately :-(
| akmarinov wrote:
| 0 chance of that happening
| JanSt wrote:
| yeah, apple is pretty stubborn on that one. I'm glad we have
| Chrome
| dmitriid wrote:
| Both Safari and Firefox are stubborn on that one (and most
| other hardware APIs), and for good reasons.
| whywhywhywhy wrote:
| They can code working security models for other features
| so fingerprinting isn't a good reason.
|
| Firefox is actually looking at WebMidi now so they've
| clearly had a change of heart. Apple will never do it
| because it means you can make hardware devices that
| interact with iPhones without going through the App
| Store.
| hbn wrote:
| The nice thing about Chrome is that any and every feature
| is implemented.
|
| The bad thing about Chrome is that any and every feature is
| implemented.
| aeharding wrote:
| There's still some things Safari prioritizes that other
| vendors don't have. For example, Chrome (and FF) still
| haven't fully implemented CSS colors level 4.
|
| Chrome and Firefox are still clamping all CSS colors to
| sRGB. You literally can't render anything outside of sRGB
| with CSS. And almost all modern Apple devices are capable
| of the display-p3 color space.
|
| This is very noticeable when rendering reds and greens,
| especially.
|
| https://webkit.org/blog/10042/wide-gamut-color-in-css-
| with-d...
| SemanticStrengh wrote:
| this is not true anymore, chromium added support for
| other color spaces this year
| aeharding wrote:
| Chrome supports CSS level 4 color functions, but they're
| clamped to sRGB. AKA, basically useless.
|
| https://bugs.chromium.org/p/chromium/issues/detail?id=106
| 861...
|
| Edit: Actually, I don't think Chrome even supports CSS
| level 4 color functions. (It sounds like it's part of
| interop2022 though!)
| SemanticStrengh wrote:
| Do you know when the clamping will be removed? I was
| referring to this
| https://chromestatus.com/feature/4592567062626304
|
| Have I hallucinated? I wzs sure support for it was added
| recently
|
| Edit according to the last comment in the issue you
| linked, this is on the 2022 roadmap, it's about time to
| properly support HDR!
| charlescooper wrote:
| I have been using Firefox & macOS for about the last 4-5 years. I
| primarily use it because I enjoy the bookmark sync between my Mac
| and linux desktops and because I try using open-source software
| as much as reasonably possible. However I will used a closed-
| source product when I feel it is better than the open source
| option. (E.g. MS Excel) It seems like Safari has been rapidly
| improving as of late. Any recommendations to try it again over
| Firefox? Would be a bit annoying to find some sort of "bookmark
| sync" solution again, but something good probably exists out
| there.
| corrral wrote:
| The main selling point is that it's far more respectful of
| system resources than its big two competitors. Noticeably lower
| power use, reduced effects on performance of other software
| outside the browser.
|
| If the rest of your stuff is also Apple, browser sync is a
| pretty solid Just Works thing, which can be a benefit of using
| it, but you're not all-Apple, so that benefit's out.
|
| [EDIT] "So what are the downsides?" worse dev tools, worse add-
| on ecosystem. Sometimes it's missing engine features that FF
| and Chrome have (this never hinders me at all in practice, with
| my usage patterns, and in fact I'm usually glad when they
| choose not to uncritically and promptly implement every single
| feature Google adds to Chrome, but I understand it bothers some
| people a lot, so would definitely count against Safari if those
| features are things you really want/need)
| bastardoperator wrote:
| This is exactly why I use safari, it's not perfect, but it
| respects the battery life to a noticeable extent.
| MBCook wrote:
| I love it. In my eyes it's the best browser because of that
| and it's Apple ecosystem integration.
|
| It also feels _so much faster_. Maybe the others have
| caught up on the Mac over the years. But it used to be
| night and day.
|
| I even use it for development. The dev tools are fine for
| me. I agree FF/Chrome are better, so I use them when I need
| it. Especially for the React or Redux plug-ins.
|
| But for standard JS errors and CSS tinkering I find Safari
| works just fine.
| danielvaughn wrote:
| I didn't know that it was lighter on system resources, that's
| interesting. Makes me wonder if a FF-based Electron would
| ever take off, because the main issue with Electron apps is
| the insane amount of memory consumption (last I checked
| anyways). Especially if you have multiple electron apps
| running simultaneously.
| corrral wrote:
| > I didn't know that it was lighter on system resources,
| that's interesting. Makes me wonder if a FF-based Electron
| would ever take off, because the main issue with Electron
| apps is the insane amount of memory consumption
|
| During my own Great Browser Migration, part of my
| motivation for going from FF to Chrome was that Chrome
| caused fewer beachballs when I wasn't even using it (I'm a
| tab hoarder, so it's my own damn fault, kinda). My switch
| to Safari came when I realized it _almost never_ caused a
| beachball (plus the huge battery life improvement).
|
| I'd hope Chrome and FF have both gotten better (this was
| about ten years ago), but I still use FF off-and-on (though
| mostly on Windows) and my sense is that it hasn't improved
| a ton on that front. My understanding is you can fix much
| of this with various add-ons, though, at least on Firefox
| (less sure about Chrome). The Great Suspender, stuff like
| that. I've not used them, though.
| scns wrote:
| AFAIK Firefox has The great suspender built in.
| lowwave wrote:
| > and in fact I'm usually glad when they choose not to
| uncritically and promptly implement every single feature
| Google adds to Chrome, but I understand it bothers some
| people a lot, so would definitely count against Safari if
| those features are things you really want/need)
|
| Thanks someone for bring it up. More features Chrome add are
| in the larger scheme of thing invates our privacy, WebTorrent
| (leaks IP addresses of the other peers). WebGPU leaks
| hardware info finger printing, etc.
|
| By using web browser I expect some sort of sandboxing. Why do
| I need all these features in a document based viewing portal?
| jazzyjackson wrote:
| I moved from Firefox to Safari solely because I can two-finger
| pinch into a grid view of open tabs - and also it has a 'share'
| button that integrates with my Mac and allows me to dump
| websites as PDFs to my knowledge repo (DEVONthink), I was never
| able to organize bookmarks in a way that I looked at them ever
| again.
|
| There's a pretty slick tab grouping interface but I always
| forget its there.
| Daiz wrote:
| Gotta say, really disappointed with the fact that instead of
| Safari making 100vh actually mean 100% of viewport height like
| it's supposed to, they instead present us with all these new
| viewport units, all to fix a problem that was caused by their own
| deviation from the spec to begin with. And of course they're not
| going to do anything about 100vh even with all these new units,
| because how else are we going to force developers to use our
| special units to cater to our browser's quirks!
| lilyball wrote:
| What spec? I just looked up what the issue is with vh on mobile
| and the very first resource I found talked about how the spec
| isn't clear on how it's supposed to behave in the presence of
| movable chrome, like the address bar on mobile browsers.
|
| It also says that Safari's initial implementation updated `vh`
| when the address bar changed visibility and this caused a bad
| jump in layout, which is why they changed it to ignore the
| address bar so it's a fixed value instead. And it says Chrome
| mobile followed suite as well, which means it's not just Safari
| that thinks the "fixed value" approach is better on mobile.
| Daiz wrote:
| I've yet to meet a single developer who likes what Apple did
| with 100vh. And it's why all my projects to date that want to
| use viewport height in CSS have ended up adding a JS snippet
| that sets a --vh CSS variable to window.innerHeight on
| resize, because I have no interest in dealing with Apple's
| special boy CSS behavior. And really, even Apple itself
| admits that their 100vh solution is troublesome - they
| wouldn't have introduced all these new units otherwise! Even
| if the saner solution would have been to just change their
| idiosyncratic 100vh behavior to what developers actually
| expect from it.
| rikschennink wrote:
| Haven't checked yet but assume that canvas memory management is
| probably still broken.
| SemanticStrengh wrote:
| when will they support sharedworkers..
___________________________________________________________________
(page generated 2022-05-16 23:01 UTC)