We all know the good ol alert() method

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'
    }
   }
 ]
});

Why not just use <dialog>?

Not Widely supported, and way easier to change a method then to implement <dialog> even though it would eventually be.

Aside from that, this is browser’s native UI:

Could be made easier (No styling) but can add buttons.

or for styling only:

• fontSize
• boldness
• italics

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().

I mentioned

and can be disabled

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.

By stop the world you mean switch focus? to the tab. Browsers could change the alert() to only show up on the tab and not switch.

And its an Alert the alert should be the main focus, that’s kind of the point of the word alert.

Not sure what you mean by:

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.

Alright this idea is dead, no biggie just wanted to see thoughts, I’m not capable of closing this, but it’s over.

Thanks for the feedback.

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.

@Edwin_Reynoso What do you think?

@ato fetch is the replacement of XHR