[Proposal] Toast UI element

Introduces a standard, customizable toast notification HTML element, and a JavaScript API to provide easy use for common cases.

Modern web applications have grown in the scale of what actions they can offer, to the point where clear feedback is an essential part of a complete, accessible web experience. Toast UI elements are a common way to provide this feedback, and a variety of libraries exist to provide toasts. Creating a built in toast would allow those libraries to layer their implementations on top, and allow web developers to use a simple, unopinionated toast without having to bring a new library into their project.

We have an explainer and research on GitHub.

We’d like to move the explainer from my repo to WICG.

We’re excited about this on the AMP Project.

We currently have an example of how to create a snackbar on amp.dev. This will allow us to ship a more encapsulated component without having to add to our bundlesize.

The research as shown in the GitHub project is thorough and covers the use cases we need.

Note that there is already a request for TAG review and an intent to implement.

Submitted to TAG seems early, so I jumped in with a GitHub accessibility issue before it gets too far to ensure we are considering leverage existing ARIA roles so we can bake the accessibility in from the start.

Surely this could be named something more broadly relatable and apparent than “toast”? This seems like a very strange spec to so quickly strongarm as a standard.

@awesomerobot the naming is indeed something that’s come up a few times. There’s an issue to discuss, a study group full of surveys of existing libraries (mostly “toast”, except for a few Google ones that use “snackbar”), and a pull request that cites some other sources for the name. It turns out it’s a fairly common UI pattern across the web, with that particular naming!

I’m also a bit confused by your idea of “quickly strongarm as a standard”. We’re specifically posting for community discussion; there’s no pull request to the HTML Standard out, and even if there were, that would not be merged until it met the criteria for additions.

been developing on web for over a decade, never heard it until now. toast also has @ least two meanings in english.

Yes, it seems to be used within certain frameworks — but it’s obscure enough that I had to look it up (and I’ve even used some frameworks with toast components available!).

I think the problem is that it’s nearly impossible to guess at what it means unless you’ve previously used it in this narrow context within a web framework.

HTML5 introduced new semantic elements, and semantic naming has continued with newer elements like dialog and menu. Even the HTML4 dl element feels more semantic, despite being obscured as an acronym.

That in mind, toast describes the behavior of the motion related to the element and has little to do with its content or context. Along with the expectation that the animation would be customizable, it’s very likely that a “toast” element wouldn’t even feature the animation that provided the name.

I think @dauwhe best summarizes why people don’t feel great about the approach so far: https://gist.github.com/dauwhe/065b0c2b4ffae7b00e103e63edab25b9

It does not appear that any discussions happened with other browser vendors or standards bodies before the intent to implement.

Why is this a problem? Google is seeking feedback on a solution, not on how to solve the problem. Is a new HTML element the best solution for whatever problem <std-toast> is trying to solve? I have no idea, and Google is already so invested in this solution that they are telling the world they will be writing code.

Heh, those are interesting examples. Without prior experience with UI frameworks, how would you know that a dialog refers to a mini-window that pops up over the main one, instead of two people talking? How would you know that a menu refers to a list of clickable options, instead of something you order food off of? In the end, pretty much every UI element name is a metaphor, or term of art. There may be a better one for toast, but I’d be loathe to invent our own on the web.

There definitely seems to be some misunderstanding. We’re 100% looking for feedback on how to solve the problem. The issue tracker is already full of people giving feedback on ways to solve the problem!

Dialog and menu have been both used in context of interfaces for decades before they were introduced as standards to HTML. You can find “dialog box” and the interface-specific definition of “menu” in english dictionaries.

Precedence aside, they are also metaphors that describe the content in some way, even if loosely.

A dialog is conversation between people, a dialog in an interface is communication that typically prompts a response. A menu in a physical sense is a list of food offerings, a menu in an interface is also a list of offerings.

toast is only descriptive of the motion and not the content (not even loosely descriptive of the content!), and similar to the notoriously deprecated blink tag… once you customize the motion even that descriptive relationship is lost.

Good to know, thanks for being responsive!

I’m incredibly excited for this proposal. I can’t speak to the specific, technical merits of the proposal, having so little (none) standardization experience, but I’m really grateful to the folks who are working to add common userland items into the platform.

Personally, I appreciate the proposal, but don’t find it particularly compelling: it doesn’t seem to provide any system level integration (already achieved with notifications API) nor does the “saves bytes” argument strike me as particularly compelling, as the body of the toast is where the weight is. It seems to replicate CSS functionality, via the duration member, and so on. The accessibility aspect of this is compelling, but feels to me that’s best delegated to something like AOM?

I’ll see what other Mozilla folks think (will file a formal standards position), and I’m open to being convinced otherwise, but my initial reaction would be for Firefox to not support this - and that going down this route of might actually be harmful: it’s standardizing things at the wrong level.

In general my opinion is: anything that can be a library, should be. Similar to kv-storage, this appears to be a feature that adds zero actual new capabilities to the web platform, only building on top of existing features. <dialog> at least introduced new behavior with ::backdrop and inert DOM trees behind the dialog.

If there are issues with libraries, a new and better library can be created. Browser makers like Google have considerable developer evangelist resources and reputation to push such a solution. A good example is the apparent success of ComLink, a popular library for Web Workers made by Google. Libraries can also actually end up better than built-in features in the long run, since they have so much more scope to iterate and innovate in the long term, without the monumental backwards-comaptibility concerns browsers have to deal with. Meanwhile built-in features can easily turn in to compatibility deadweight, a good example of which is HTML imports (which could also have been a library - even the newer HTML modules could be too, which I am similarly sceptical about).

Further, most new features need a polyfill to help get them off the ground. If the polyfill has no downsides to the built-in feature, why not just only use the polyfill? Then you can skip the whole standards process and free up all that time for more meaningful features.

Everything I’m arguing here is basically the extensible web manifesto, some of the signatories to which are apparently also promoting this feature. So I have to ask, have we given up on the extensible web manifesto? If so, for what reasons?

No, not at all! In fact, what we’re doing is we’re finally fulfilling the purpose of the extensible web manifesto:

• Allow web developers and browser-initiated libraries to take the lead in costly explorations.
• Simplify and streamline the longer-term process of standardizing new APIs, which will already have implementations and significant real-world usage.

Web developers and browser-initiated libraries have very much taken the lead in explorations around things like simple key/value IDB wrappers, or toast libraries, or toggle switches, or virtual scrollers, or… Now it’s time to roll up our sleeves and do the hard work of putting things in the platform.

Other modern computing platforms, out of the box, provide high-level functionality. The web suffers in this regard, by pushing everything onto the shoulders of app developers. On Android, to use a toast, the story is “use the Snackbar class.” On the web, the story is, “choose between all these different libraries. Some of them have accessibility problems. Some of them don’t work in browsers you target. Some of them are framework-specific. Some of them are unmaintained. Some of them are maintained by someone waiting for usage to take off before they can convert it into a cryptocurrency miner. Good luck!”

This leads to the web becoming a fundamentally un-ergonomic platform, with a high barrier to entry that discourages new developers, and makes it an unattractive choice compared to native platforms for experienced developers. And, of course, it leads to bloated bundle sizes, but that point has been beaten to death a thousand times.

By fulfilling the extensible web manifesto and paving the cowpaths, instead of stopping halfway through the process and forgetting why we’re encouraging library developers to create a cowpath in the first place, we can counteract these trends.

I hope that helps clarify why we believe that there’s room for HTML to evolve, instead of leaving everything to libraries!

I’ll respond to this specific point: toast libraries are not cheap. We can do more work to quantify this, but e.g. take a look at how much code goes in to a popular React toast library or a popular Angular toast library.

You can always ask developers to add ARIA roles, states, and properties (or use AOM to do so programmatically). History has shown that most will not. Instead, what works well is having built-in platform functionality with accessibility baked in—whether that be something simple like <main>, or something more complex like <input type="range">, or this proposal. See also the discussion happening at https://github.com/jackbsteinberg/std-toast/issues/25 about how this helps give first-class support to certain roles that previously had no HTML counterpart, i.e. relied on developers consciously doing the right thing to their <div>s.

I appreciate this. This is really a true issue. However, I’m slightly skeptical that introducing a set of these browser-backed standard built-in modules is the way to solve it.

The reason the web is “is becoming a fundamentally a un-ergonomic platform with a high barrier to entry that discourages new developers, and makes it an unattractive choice compared to native platforms for experienced developers” is because these working groups have had a history of shunning very low-level features that these frameworks provide–not new standardized elements–low-level features. This is why the community has created new frameworks and all these different build tools: to provide low level features that browser vendors have failed to work with the community to implement. Working groups have gotten better over the years with accepting community ideas, but we’re still not there yet. For instance, we still can’t build a full-scale single page application without a bunch of lower-level dependencies and/or build tools and/or frameworks. We need to lean on frameworks to do very basic things like route single page applications to show HTML/components, to perform type checking, and use third-party dependencies without build steps-- we can’t even extend any HTML elements beyond HTMLElement or use CustomElements without a - (dashed prefix)!

I just don’t think introducing higher-level components of this magnitude is smart right now. We should wait until we solve all the lower level issues like mentioned above first. And we are… so I’m not against these efforts, I just think this may be an issue of timing.

Well if somebody reputable like Google makes a library that solves all of these problems the same way std-toast would, then couldn’t the answer to this question just be “use Google’s library”?

I also feel like this might be skipping a step here. Why not first release it as a library anyway as a step before standardisation? This will help trial it in the wild, getting feedback and having lots of flexibility to iterate and improve it. Once it’s established and stable, if everyone’s already using it, problem solved. If there’s still some kind of benefit left to building it in to the browser, then that would be the time to do it.

Having read @mkay581’s view it’s also an interesting question to pose: is the ultimate goal to standardise and build in something like React or Angular in to the browser as well? Is that a good idea? And if that doesn’t happen, won’t the questions remain “which framework do I use? Is it accessible? Do I trust them?” etc.

OSs like Android do bundle UI libraries as core libraries, and I can see the logic of trying to replicate that for the web. However the web has always been a very different platform. For example over the years OSs tend to deprecate and replace parts of their built-in UI libraries - and sometimes replacing them wholesale with entirely new libraries, deprecating the old ones, and then eventually forcing all developers to update. OS developers can often get away with this, using store upload requirements to force the issue. Sometimes they can’t though, like how Windows still ships Win32 APIs from decades ago which are now superseded but necessary for backwards compatibility. I imagine this is the more likely destiny for browser UI components, given their similarly stringent backwards compatibility requirements.

Also looking at Android’s Snackbar, it appears to be part of the material design components library, which appears to be shipped separately to the OS. So is it fair to say it’s not actually built in to the Android OS?

I think we, i.e. the larger web community, have done that! See https://github.com/jackbsteinberg/std-toast/tree/master/study-group. Now’s the time to take that experience and feedback and iteration, and put it in the platform.

But my point is: why not release std-toast (and other elements in development) as libraries first?