Yet could use some improvements so devs donāt have to create their own, dialog to show a simple alert message or import a library just to have different styling.
Proposal
Thereās only so much alert() could do, so not much to style
Have alert() take a second argument:
alert('This is the message', {
// Title
title: {
// All styling
color: 'black'
},
// The box where the message displays
messageBox: {
// All Styling
color: 'white',
background: 'lightblue'
fontSize: '15px'
},
// There could be added buttons, which ONLY have a title and onclick handler and styles
buttons: [
{
title: 'Yes',
onclick: function() {...},
style: {
color: 'White',
background: 'lightblue'
}
},
{
title: 'No',
onclick: function() {...},
style: {
color: 'White',
background: 'lightblue'
}
}
]
});
It seems odd to propose a new feature with no support and cite that an alternative is not widely supported as a reason to make the alternative.
Also all the styling options look like a slow, painful way of reinventing CSS. <dialog> already lets you do any styling that HTML is capable of, making it far, far more powerful and flexible. If you want <dialog> to look more like the browserās native UI, perhaps there are features which could help with that instead.
Itās my impression that alert- and confirmation dialogues are features there is popular agreement should be purged with fire. But due to backwards compatibility concerns and their wide adoption in the wild, no vendors are likely to commit to that.
Incentivising more use through adding more features is not the right way to go about it, I think.
I want to second what @AshleyScirra says, and add that <dialog> is a more pregnant alternative since it uses regular web primitives. alert() has a range of issues to do with how itās implemented:
They lock up the main JS thread, preventing scripting
Commonly implemented as a native toolkit dialogue
Locks up the UI when present (in some browsers)
Implementation varies greatly between UAs, no clear interop except that they put the browser into an unrecoverable state (seen from contentās point of view) until the user performs an action that resumes the web runtime
What I meant by being the browserās UI is that it belongs to the browser, part of the browser instead of the page. With <dialog> itās the pageās UI.
With alert() if Iām focused on another tab, the tab gets focused, and also can be disabled. Whenever the user wants to.
Also I just realize what I have above would be slow so and annoying to set each time a message wants to be shown, so a method part of alert.setUI or something else would be best:
alert.setUI({
// same thing as above
});
Thatās done before calling alert, and now I can call alert(message) in the future with the above applied styling/buttons.
@ato Also Iād disagree the only thing Iāve ever read about alert() is being bad for debugging, to use console.log() instead.
Forcing the browser to switch to the tab, and locking up the page by forcing browser UI on top of it, are user-hostile features. These are not benefits of alert(), they are disadvantages. I agree with @ato that they should be purged with fire In fact, alert() is so annoying most browsers add a āPrevent this page from showing any more alertsā option so that users donāt have to deal with them any more. I think it is more likely that alert() will be removed entirely than anything will get added to it, especially given you can do absolutely anything you like with <dialog> and without any of the pains of alert().
Well we all know its not going anywhere because there are sites that depend on it, and still could be useful, I think most new sites donāt use it because thereās not much use of it, you canāt customize it the way you want to. And its an alert() it should lock up the page, and be synchrounous. Part of the browser UI, so you probably also donāt like the browserās UI box for permissions?
The browsers UI box for permissions is necessary: since the connection canāt be established (and therefore the page not even loaded) until the correct authentication is given, a modal browser popup is warranted. A normal web page should not make use of any synchronous stop-the-world UI features, itās an out-of-date UI paradigm from the 90s that needs to die.
Adding tonnes of functionality to fix alerts is counter intuitive when <dialog> exists. Certainly the support is not good however the behaviour is shimmable.
If your motivation is that you want a JS api that builds a native <dialog> that behaves like a good web citizen then perhaps there is time for that. Render blocking and adding functionality to something that is basically only used for debug is going to lead only to bad issues.
Whenever <dialog> gets enough traction in browser, Iād be interested to discuss the possibility of marking Window#alert and Window#confirm as deprecated features.
As with synchronous XHR itās obviously not possible to remove these features, but we can similarly emit a warning in the web console saying we discourage its use in favour of some replacement technology.
In fact,