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

231–240 of 311 posts

Re: New WebKit features in Safari 15.4

#231

Post by jeroenhd »

Jyaif wrote: post #226
jeroenhd wrote: post #211

Earlier quoted context omitted.

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…

> you're buying into a platform where you don't have the option to find alternatives On ChromeOS devices you usually can install a regular linux distribution though.

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.

Re: New WebKit features in Safari 15.4

#232

Post by drcongo »

inopinatus wrote: post #209
dmitriid wrote: post #204

Earlier quoted context omitted.

> 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”.

There's some impressive projecting going on here.

Re: New WebKit features in Safari 15.4

#233

Post by tarsinge »

inopinatus wrote: post #135
culi wrote: 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…

> 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?

Re: New WebKit features in Safari 15.4

#234

Post by ksec »

astrange wrote: post #227
ksec wrote: post #185

Earlier quoted context omitted.

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.

WebP is a bad idea, which is why they're updating it. We should all ignore it until it goes away. Amusingly there's also a WebP lossless which is a completely different algorithm they just let a random employee invent.

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%.

Re: New WebKit features in Safari 15.4

#235

Post by bryanrasmussen »

astrange wrote: post #228
bryanrasmussen wrote: post #191

Earlier quoted context omitted.

>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)

https://bugs.webkit.org or https://developer.apple.com/bug-reporting/

Thanks!

Re: New WebKit features in Safari 15.4

#236

Post by barrell »

inopinatus wrote: post #135
culi wrote: 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…

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.

Re: New WebKit features in Safari 15.4

#237

Post by dmitriid »

inopinatus wrote: post #209
dmitriid wrote: post #204

Earlier quoted context omitted.

> 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”.

> 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.

...

And this entire comment: https://github.com/WICG/webcomponents/issues/509#issuecommen...

--- end quote ---

So did Safari endorse Web Components? Yes. And they still do. See, for example, Template Instantiation Proposal (among many other things): https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

Did Safari ever support `is=`? No.

Let's see their endorsement again:

--- start quote ---

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.

--- end quote ---

I would also recommend you read this comment on the whole process and "obligation to implement" and other things (it's not from Apple): https://github.com/WICG/webcomponents/issues/509#issuecommen...

> and you can draw a straight line from Apple’s overwhelming institutional arrogance to Safari being the “new IE”.

There's definitely a PR manager in Chrome who gets a bonus every time this line is repeated. See breaking the web forward: https://www.quirksmode.org/blog/archives/2021/08/breaking_th...

Re: New WebKit features in Safari 15.4

#238

Post by vetinari »

dwaite wrote: post #217
vetinari wrote: post #207

Earlier quoted context omitted.

You would not; you must grant a permission to push notifications to the site first.

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.

Re: New WebKit features in Safari 15.4

#239

Post by dmitriid »

phantomread wrote: post #47
nikodunk wrote: post #17

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

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

And this was one of the many reasons why neither Safari nor Firefox implemented . It was only implemented in Chrome.

In 2018 Domenic Denicola mentioned that it's possible dialog should be fully removed as there's no interest in implementing it: https://github.com/whatwg/html/pull/4184#issuecomment-440405...

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 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.

Re: New WebKit features in Safari 15.4

#240

Post by zild3d »

adam_arthur wrote: post #146
avazhi wrote: post #143

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

Legit the only reason I don't use iPhone is due to being forced to use Safari (or Safari rendering engine wrapped)

can't you set a default browser to something else?
Post reply on HN