New WebKit Features in Safari 15.4

• caniuse

  387 5,500 9.5 JavaScript

  Raw browser/feature support data from caniuse.com

  If you check the "relative usage" button here in the top-left and consider old devices, how long until we can use this? https://caniuse.com/?search=dialog

  There's still 1.5% of iOS users that can't use webp images for example and that's been out for ages: https://caniuse.com/webp

• dialog-polyfill

  8 2,427 0.0 JavaScript

  Polyfill for the HTML dialog element

  

  This does not make sense. Of course new functionality won't work on old browsers.

  is easy to polyfill well: https://github.com/GoogleChrome/dialog-polyfill

• SurveyJS

  surveyjs.io

  sponsored

  Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

  

• a11y-dialog

  3 2,370 8.7 JavaScript

  A very lightweight and flexible accessible modal dialog script.

  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.

• webmidi-test

  2 6 1.1 HTML

  🎵 Web MIDI Test page with basic device hotplug support

  

  I've been regularly checking that page, delighted with every step of progress as WebMIDI gets implemented in Firefox.

  In about:config, I have dom.webmidi.enabled set to true. I'm using this test page and waiting for the day it starts working for regular version of Firefox.

  https://versioduo.com/webmidi-test/

• WHATWG HTML Standard

  137 7,666 9.4 HTML

  HTML Standard

  

  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.

• standards-positions

  178 595 7.6 Python

  

  I was responding to WebUSB. Both Firefox and Safari view them as harmful in their current form. They are not really on a standards track for now, they are "Draft Community Reports" or somesuch.

  For something to become a standard that something needs to independent implementations. Before that it's just some browser's prototyping stage, no matter how many times Chrome will tell you otherwise.

  According to chromestatus, WebMIDI now has positive position from Mozilla and negative position from Safari: https://chromestatus.com/feature/4923613069180928

  Just three years ago Firefox's position was also largely negative due to unresolved security issues: https://github.com/mozilla/standards-positions/issues/58 It's possible those issues are now resolved, that's why it's making its way into Firefox. This means that Safari's stance may also change.

  Same goes for other hardware APIs: from the point of view of both Safari and Firefox those specs have security and privacy holes the size of Jupiter. Not to mention that the quality of some of these so-called specs is very low. If/When these issues are resolved, we may see them implemented in these browsers, too.

Suggest a related project