I don't think anyone would say web-standards are excellent, well designed and well-managed.
All the wonderful value is in that they are standard. The web is great in its ubiquity. Love the web! Sure it's a mess, how could it not be?!
<dialog> is a win here in my view, especially for internal admin tools, I don't want to care about the latest flavor of frontend insanity. I just want to save screen space and open content as modal overlay on top of a main view.
They should err on the side of keeping the APIs small. Maybe it would be better if Web Components weren't a thing. I thought ARIA was handling dialogs well when it comes to accessibility. I like the idea of splitting JavaScript into JSSugar and JS0. (It will be nice if in the Deno lawsuit that the USPTO clarifies that Oracle owns the term JavaScript and JS is a free-for-all.)
> Do you know that Chrome argued that <dialog> should be removed from the platform because it's a bad API with multiple issues?
That's not at all what the comment you linked to says. It says there was an open question about if <dialog> should be removed from the spec because interest hadn't materialized from Firefox and Webkit for the element after four years (and wouldn't for another two years after that).
What I'm saying is that the goal of standards and cross-platform support across time is valuable. The "open web" is a good thing for humanity.
Work towards this goal is a huge shit show. And messy. But it's a good goal.
The flavor-of-the-month frontend insanity is not serving this "good thing for humanity" goal as I call it. It's all well-intentioned and I'm not looking a gift horse in the mouth. But it is different.
>Last year the major web browser vendors decided to change the standard (remember, HTML is now a "living standard")
SIGH...
To be honest, I think it's unlikely you will ever try to open the same dialog modally twice. If you need user input to open the dialog, and a modal dialog blocks user input, the only way for this to happen is if you have an input on the dialog that opens the dialog. If you are using asynchronous tasks to open the dialog, then you probably should keep track of what is open and what is not.
The same thing would happen if you were doing it on Qt, for example.
> To be honest, I think it's unlikely you will ever try to open the same dialog modally twice.
This is a strange reaction to the blog post, because as you read, it's a certainty that my code did try to open the same dialog modally twice. This was a bug, of course, which would have been revealed in development if not for the change in the standard.
I was really hoping the dialog element would end up as a customizable await confirm/prompt on steroids that wouldn't get flagged by every browser if you open it more than once. But it's more of a glorified div.
There's more where that came from. Google Chrome also did URLPattern, which I hope Chrome and Safari will hold firm on not supporting. The compression streams API wasn't bad, but it's a tiny API. I see a pattern here: Google sucks at UX and DX.
Edit: I looked up standards positions and both support URLPattern.
I did, and looked it up and Firefox chose the support position for it as well. I looked at the API again and I guess it's all right. It doesn't help much with tree-based routing like Roda (https://roda.jeremyevans.net/index.html) but it seems useful for simple stuff.
All the wonderful value is in that they are standard. The web is great in its ubiquity. Love the web! Sure it's a mess, how could it not be?!
<dialog> is a win here in my view, especially for internal admin tools, I don't want to care about the latest flavor of frontend insanity. I just want to save screen space and open content as modal overlay on top of a main view.