7 ms·

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

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

phantomread 5y ago
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#incoming-dialog 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 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.
- dmitriid 5y ago
  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-440405059 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 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.
culi 5y ago
And just like that, Safari has surpassed Chrome in interop 2022 https://wpt.fyi/interop-2022 https://wpt.fyi/interop-2022
- alwillis 5y ago
  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.
  - culi 5y ago
    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.
- _-david-_ 5y ago
  Click stable. Safari is nowhere close.
  - gsnedders 5y ago
    That'll still be Safari 15.1, alas; 15.4 should be close to the experimental score shown.
    - jtbayly 5y ago
      Why haven't the stable versions 15.2 and 15.3 been tested? Will 15.4 be tested?
      - gsnedders 5y ago
        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…
- 5y ago
deleted 5y ago
[deleted]
dmitriid 5y ago
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.

phantomread 5y ago

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#incoming-dialog 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 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.

dmitriid 5y ago
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-440405059 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 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.

culi 5y ago

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

alwillis 5y ago
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.
- culi 5y ago
  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.
_-david-_ 5y ago
Click stable. Safari is nowhere close.
- gsnedders 5y ago
  That'll still be Safari 15.1, alas; 15.4 should be close to the experimental score shown.
  - jtbayly 5y ago
    Why haven't the stable versions 15.2 and 15.3 been tested? Will 15.4 be tested?
    - gsnedders 5y ago
      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…
5y ago

deleted 5y ago

[deleted]

dmitriid 5y ago

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.