I agree that this is a huge improvement, but it's also over a decade late IMO. This should've been accomplished well before now, especially given that the issue has been there since the beginning.
By and large browser vendors for the longest time, even today still in many respects, repeatedly ignore pleas for more elements that cover common use cases.
Even when they do arrive, they can be half baked - like dialog or details / summary - and that doesn’t help matters
How are those half-baked? No smooth transition for details/summary, maybe?
Dialog seems to work well enough with little to no javascript required:
<dialog>
<h3>Warning:</h3>
...
<button onclick='this.closest("dialog").close()'>Dismiss</button>
</dialog>
Forms have some special quirks inside of a dialog.
The biggest thing though, is for the life of me I don't understand why you can't open and close a dialog without JavaScript. There's no way to do it.
You can use popovers like this without JavaScript:
<button popovertarget="some-element" popovertargetaction="show">Open</button>
<div id="some-element" popover="auto">
<button popovertarget="some-element" popovertargetaction="hide">Close</button>
</div>
I don’t think there’s any way at present to open a `<dialog>` element specifically without JavaScript, but command/commandfor handles this and was recently added to the HTML specification:
<button type="open-dialog" target="dialogId">Open Dialog</button>
...
<dialog id="dialogId">
<button type="close-dialog">Close Dialog</button>
</dialog>
You can do this right now already:
// For opening
<button onclick='document.querySelector("#dialogId").showModal()'>Open</button>
// For closing
<button onclick='this.closest("dialog").close()'>Close</button>
> It would just make so much sense.
That way above that I propose is about as sensible as the way you propose. If there are any problems with my proposal that are solved by your proposal, I'd love to hear it.
For all practical purposes, there is no difference between the two.
I understand that the `onclick` wouldn't fire in browsers where JS is turned off, but in that case (no JS) you're going to have an awful user experience using dialogs even with builtin open/close attributes for dialogs.
I remember Opera, before it was bought, had the best support for html5 elements and date/time inputs were the best (along with almost all others). Sad to think that a leader in this area was sold off, and not to a buyer that cared about usability and the web the way Opera did.
The solution is to make html elements extensible.
With the `appearance: base-select` css rule, we now have a standardized way to extend <select> with html and css, (and we have the potential to declaratively extend intractability too with invoking commands without needing to reach for JS)
The solution would be to make Apple ship this:
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
It's especially obvious once you're making forms outside of HTML and you realize that it's not any simpler with any less UX consideration. The only thing that changed was the language you're writing that polish in.
It is crazy to think what we only just have in anything non JavaScript in the past 20 years.
This 8,000+ word article on Safari 18.4 (released today, BTW) doesn’t read like an organization that doesn’t care about the web [1].
[1]: https://webkit.org/blog/16574/webkit-features-in-safari-18-4...
I don’t want to debate if a mega corp cares or not, but compared to how UI frameworks were in the 90s, the developer experience is anemic.
I don’t know if HTML, CSS and JavaScript are the best path forward. Maybe they are doing exactly what their spec set out to do.
But we need something better that doesn’t leash one to an ecosystem that takes 30% of your revenue.