Hacker News Reader

Comment by nikodunk | Hacker News Reader

Now all major browsers support the <dialog> 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 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.

And this was one of the many reasons why neither Safari nor Firefox implemented <dialog>. 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 <dialog> 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.

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.

Click stable. Safari is nowhere close.

That'll still be Safari 15.1, alas; 15.4 should be close to the experimental score shown.

Why haven't the stable versions 15.2 and 15.3 been tested?

Will 15.4 be tested?

Uh, it's 15.3 that's being run, I just can't write the right number it turns out. (I honestly have no idea why I said 15.1!)

15.4 should show up in day or two, there's a bunch of latency in how those metrics are generated currently…

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 would be irreparably shattered by even contemplating an amendment of this position.

Thanks to such attitudes, Safari remains the "new IE", the problem browser for which developers must find workarounds.

(1) e.g. https://github.com/WICG/webcomponents/issues/509 and other forums besides

Curiously, the above remark was at +4 and is currently -2, which really just goes to show how polarising Apple is by timezone.

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.

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

That's how how standards work

Their reasoning was evidently not accepted.

If Apple do not wish to implement the standard, they should leave the steering group.

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

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

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.

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 would go their own way and propose and implement alternatives. Better than taking Google's highway. I would prefer a fragmented ecosystem over the Tyranny Of Chrome that wants to destroy your privacy and the spirit of the world wide web.

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.

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

Sure, simple websites mostly work in Safari. But we're in 2022, and indeed a lot of companies develop web apps, and not simple websites like 20 years ago.

The web itself is an app platform. The only browser preventing it to happen on mobile is Safari. Have a look at the desktop. There, web apps have replaced most native apps long ago.

> The web itself is an app platform.

It's not. And frankly will never be.

> The only browser preventing it to happen on mobile is Safari.

It's not preventing anything

> look at the desktop. There, web apps have replaced most native apps long ago.

What a strange fantasy world you live in.

Very convincing, thank you for this well argued response.

It's in the vein of your statements, and it takes too much time to explain why this is wrong. And this has been said many times before by many people far more eloquent and knowledgable than I. Yet this sentiment persists (even if it's driven by emotion on the one hand and relentless Chrome propaganda on the other).

I use a lot of web applications like tradingview.com and need web push notifications. Safari still does not support them and it’s so annoying.

That's not in contradiction with what I said. I have nothing against web apps and I'm not arguing against their success. But they don't make the web irrelevant, they are just something different, just historically built on top of the web.

And indeed when we have a look at the desktop it further proves the point, Electron apps ship their whole execution platform, basically an OS inside an OS, and it's Chrome. So the divorce between Chrome the app platform and the web has already started. Safari is a blessing for me because it force that issue to crop up and be discussed, instead of just letting the web slowly become the Google platform.

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

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.

That's definitely not representative of the general sentiment. As far as I'm concerned, probably around 95% of my debugging time is spent on Safari. Stuff usually works like a charm in Chrome or Firefox. Safari is a gigantic pain due to its plethora of bugs (and new ones appearing with each release) and missing features preventing you to easily work around them.

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

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

Reply on news.ycombinator.com