Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New WebKit features in Safari 15.4

webkit.org

Post reply on HN
Print view View original

301–310 of 311 posts

Re: New WebKit features in Safari 15.4

#301

Post by inopinatus »

tarsinge wrote: post #233
inopinatus wrote: post #135

Earlier quoted context omitted.

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…

> 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 a…

All your assumptions are wrong: I hack on lightweight framework code, and my primary development browser is Firefox.

Re: New WebKit features in Safari 15.4

#302

Post by inopinatus »

dmitriid wrote: post #237
inopinatus wrote: post #209

Earlier quoted context omitted.

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 spe…

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.

Re: New WebKit features in Safari 15.4

#303

Post by inopinatus »

dmitriid wrote: post #285
lenkite wrote: post #283

Earlier quoted context omitted.

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…

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. [1] https://twitter.com/rniwa_dev/status/1352322006448947203

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.

Re: New WebKit features in Safari 15.4

#304

Post by AbacusAvenger »

arilotter wrote: post #268
AbacusAvenger wrote: post #167

Earlier quoted context omitted.

Out of curiosity, what are the WebGL bugs you ran into?

I haven't made a minimal viable repro yet, but - our game renders perfectly on any iOS lower than 15.4, but on 15.4, this happens: https://cdn.discordapp.com/attachments/913446741154611250/95... Happens on latest Safari on MacOS, too: https://cdn.discordapp.com/attachments/476502698066182179/95...

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?

Re: New WebKit features in Safari 15.4

#305

Post by frankjr »

iknowstuff wrote: post #24
smoldesu wrote: post #10

Earlier quoted context omitted.

Right, for $2 and no access to the source code.

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.

Re: New WebKit features in Safari 15.4

#306

Post by taf2 »

jcbrand wrote: post #298
taf2 wrote: post #103

Earlier quoted context omitted.

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?

That's great news if true. Last I saw (maybe a year ago), Safari claimed they won't support shared workers at all.

SharedWorkers are in safari now as a feature you can toggle on in settings on iOS

Re: New WebKit features in Safari 15.4

#307

Post by ezfe »

frankjr wrote: post #305
iknowstuff wrote: post #24

Earlier quoted context omitted.

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.

Along with any other application...on your phone, yet you don't ask for the source code to those?

Re: New WebKit features in Safari 15.4

#308

Post by frankjr »

ezfe wrote: post #307
frankjr wrote: post #305

Earlier quoted context omitted.

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.

Along with any other application...on your phone, yet you don't ask for the source code to those?

I should have specified I'm talking about macOS.

Re: New WebKit features in Safari 15.4

#309

Post by culi »

strix_varius wrote: post #259
culi wrote: post #49

Earlier quoted context omitted.

And just like that, Safari has surpassed Chrome in interop 2022 https://wpt.fyi/interop-2022

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: - FF: 74 - Chrome: 66 - Safari: 50

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

Re: New WebKit features in Safari 15.4

#310

Post by culi »

alwillis wrote: post #53
culi wrote: post #49

Earlier quoted context omitted.

And just like that, Safari has surpassed Chrome in interop 2022 https://wpt.fyi/interop-2022

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.

Woops you're right. This was premature. But once 15.4 has been released it'll have surpassed Chrome in the stable release as well.
Post reply on HN