Live data from Hacker News

New WebKit features in Safari 15.4

webkit.org

191–200 of 311 posts

Re: New WebKit features in Safari 15.4

#191

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

>or until Apple acknowledges a bug report

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)

Re: New WebKit features in Safari 15.4

#192
post #49

Earlier quoted context omitted.

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

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…

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.

Re: New WebKit features in Safari 15.4

#193

Earlier quoted context omitted.

"Our product doesn't work in safari, use chrome or firefox instead"

The web is built on the foundation I can use any browser. You are going to break the fundamental promise just to avoid working around a bug?

Apple have already intentionally broken that promise by refusing to implement parts of the HTML standard.

Re: New WebKit features in Safari 15.4

#194

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.

I’m sure many of your users would welcome this feature but I’m personally grateful that I don’t get random notifications from websites.

Re: New WebKit features in Safari 15.4

#196

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…

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.

Re: New WebKit features in Safari 15.4

#197

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.

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…

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!

Re: New WebKit features in Safari 15.4

#198

Earlier quoted context omitted.

The web is built on the foundation I can use any browser. You are going to break the fundamental promise just to avoid working around a bug?

Apple have already intentionally broken that promise by refusing to implement parts of the HTML standard.

Which parts of HTML standard did they refuse to implement?

Re: New WebKit features in Safari 15.4

#199

Now all major browsers support the element without polyfill. Yay! https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...

Just last year the same people at Chrome who advocating for removing of alert/confirm we're advocating for removal of 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.

Re: New WebKit features in Safari 15.4

#200

Earlier quoted context omitted.

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…

They presented a clear case of why they refuse to implement them.

That's how how standards work

Post reply on HN