One day, all the sudden, I started hearing jokes about toast. I had no idea what the context was. I assumed some friends just got started telling toast jokes, which isn’t rare by any means. But it turns out it was a whole thing. It got me thinking, jeez, if I can’t keep up with this stuff when it’s kinda my job, it must be extra tough for people who actually do work for a living.
Anyway. Thankfully Jeremy summed it up nicely:
First off, this all kicked off with the announcement of “intent to implement”. That makes it sounds like Google are intending to, well, …implement this. In fact “intent to implement” really means “intend to mess around with this behind a flag”. The language is definitely confusing and this is something that will hopefully be addressed.
Secondly, Chrome isn’t going to ship a
toastelement. Instead, this is a proposal for a custom element currently calledstd-toast. I’m assuming that should the experiment prove successful, it’s not a foregone conclusion that the final element name will be calledtoast.
The drama around it, hence the cause of all the jokes and such, was the fact that it felt like it came out of nowhere and was Chrome strongarming a feature through the standards process, or perhaps kinda skipping that process. Terence’s humorous post digs into that a bit more.
I’m not sure if Google is actually doing anything nefarious here. It’s behind a flag, so I guess the point of that is to explore and research and stuff. Feels very similar to kv:storage to me, a “native module” much like a “native custom element.”
But we should be extra watchful about stuff like this. If any browser goes rogue and just starts shipping stuff, web standards is over. Life for devs gets a lot harder and the web gets a lot worse. The stakes are high. And it’s not going to happen overnight, it’s going to happen with little tiny things like this. Keep that blue beanie on.
Regarding the element itself, it’s always a bit surprising to me to see what gets legs as far as new HTML elements. Toasts just seem like a positioned <dialog> to me, but I haven’t participated in any research or anything. They are popular enough for Bootstrap to have ’em:
See the Pen
Bootstrap Toasts by Chris Coyier (@chriscoyier)
on CodePen.
I would have guessed something like dropdown menus or tabs would have been the strongest contenders for “native” web components.
Personally I feel like dropdowns would be best served through
detailsat the moment; and pretty annoying to implement otherwise.Toasts are pretty small, and have n actions that can be taken (usually 1 or none). They’re nonessential notifications to the user; and tend to come in from a singular, known place (eg bottom left, top right, bottom centre). Think
alertbut non-blocking.Personally I feel like they’ve just gone with the thing that’s easiest to write.
As for dropdowns (particularly dropdown menus), I believe that githubs’
details-menu-elementis the best at the moment (currently unpkg is down. Seriously please host your own dependencies github)…Tablists are also not great for most cases; but I see a legitimate use case for them in user-categorised content lists with many items (eg a library application like Tachiyomi) where you might know the container names before the content.
And here I am still wanting container queries like an idiot…
It feels like the Google devs just communicated something poorly but it hinted at a possible, nefarious direction for browser development and web standards. And now that we’re back in a two browser world (sort of) that doesn’t bode well. But I’m curious whether the adoption of Chromium by Microsoft means that there are now more voices guiding the direction of the project? To what extent does that consolidation help things?