@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.
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.
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.
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!
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?
We do plan to release them, as flagged implementations in Chrome, and to origin trial. I think we have plenty of experience using libraries to deliver toasts, and doing another one doesn’t add to the conversation. Rather, we can move forward by working on fulfilling the extensible web manifesto’s second half, and doing the hard work of putting something into the web standards process and browsers.
All you’ve actually done here is write a new and better library. Now you want to enshrine it in the standards process, and to me that carries at least as significant risks as it does advantages.
I also still don’t understand the argument why this has to be built-in. You gave Android’s SnackBar as an example, but that does not appear to actually be built-in to Android. Instead it is an officially sanctioned library - exactly the alternative I am proposing. So I have to ask again: why make it built-in?
I think you also have a different reading to the extensible web manifesto to me - I see this as very much in the “costly exploration” phase. You’ve invented a new and better library, but it’s not yet clear that this latest iteration of a library will achieve widespread use; nor is it clear whether a new and even better library will eventually turn up and replace it, in which case: oops! You shoulda standardised that instead. This is why I think specs should focus on the low-level platform capabilities, and leave the higher level to libraries - especially since the web platform is infamous for its high rate of turnover in libraries and frameworks (which has its inconveniences, but arguably is a sign of intensive innovation).
I think the way jQuery went demonstrates a much better approach. It wasn’t simply standardised wholesale as a complete built-in library. Instead it inspired new building blocks for the platform, such as querySelector. I think this is a much smarter and more thoughtful approach than just cutting and pasting the library of the day in to the spec.
Even if this exact library dominated the web as the way to solve this problem, and somehow you “just knew” it would never be replaced by a new and better library even over the decades to come (which to me is simply hubris) - then I would say: at least do something like kv-storage, which you opt in to by importing a standard module. Then at least as a very minimum you avoid polluting the global namespace permanently, and have options available for versioning and replacement in future.
When you have a hammer, all the world is a nail, and I suspect that to standards folk, every problem can be solved by a new standard. There are other ways to achieve the goals outlined here. I think this process needs to slow down and more serious consideration be given to alternative approaches.
Just following up on the Mozilla side. I’ve filed a request for a standards position:
I think @AshleyScirra makes very valid points. As a follow up to the argument that “libraries don’t do this well”, there is little evidence that browser vendors would do this better (and if we screw it up, it’s harder to fix… or if the Toast proposal has identified missing aria roles, let’s add those). Thus, why not just fix the React (or whatever popular libs there are out there) toast libraries instead?
Note that I started the discussion and it sat with no responses for 12 days. Given how this proposal started by looking at frameworks instead of existing standards and patterns, I am not sure it is a great supporting argument.
My main concern with the “just fix [libraries]” argument is that new libraries and frameworks are created nearly daily. Trying to stay abreast of even the most popular means constant library baby-sitting as new changes come and regressions appear.
Arguably, by targeting browsers (building native support) we have a smaller set of runtimes to manage and regressions are more likely to be addressed as browsers continue to be updated by dedicated staff.
HTML should pave cowpaths. I am not yet convinced, however, that this particular case is more than a wobbly ferret path.