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.