Toast

Shockwaves rippled across the web standards community recently when it appeared that Google Chrome was unilaterally implementing a new element called toast. It turns out that’s not the case, but the confusion is understandable.

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 toast element. Instead, this is a proposal for a custom element currently called std-toast. I’m assuming that should the experiment prove successful, it’s not a foregone conclusion that the final element name will be called toast (minus the sexually-transmitted-disease prefix). If this turns out to be a useful feature, there will surely be a discussion between implementators about the naming of the finished element.

This is the ideal candidate for a web component. It makes total sense to create a custom element along the lines of std-toast. At first I was confused about why this was happening inside of a browser instead of first being created as a standalone web component, but it turns out that there’s been a fair bit of research looking at existing implementations in libraries and web components. So this actually looks like a good example of paving an existing cowpath.

But it didn’t come across that way. The timing of announcements felt like this was something that was happening without prior discussion. Terence Eden writes:

It feels like a Google-designed, Google-approved, Google-benefiting idea which has been dumped onto the Web without any consideration for others.

I know that isn’t the case. And I know how many dedicated people have worked hard on this proposal.

Adrian Roselli also remarks on the optics of this situation:

To be clear, while I think there is value in minting a native HTML element to fill a defined gap, I am wary of the approach Google has taken. A repo from a new-to-the-industry Googler getting a lot of promotion from Googlers, with Googlers on social media doing damage control for the blowback, WHATWG Googlers handling questions on the repo, and Google AMP strongly supporting it (to reduce its own footprint), all add up to raise alarm bells with those who advocated for a community-driven, needs-based, accessible web.

Dave Cramer made a similar point:

But my concern wasn’t so much about the nature of the new elements, but of how we learned about them and what that says about how web standardization works.

So there’s a general feeling (outside of Google) that there’s something screwy here about the order of events. A lot discussion and research seems to have happened in isolation before announcing the intent to implement:

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.

Going back to my early confusion about putting a web component directly into a browser, this question on Discourse echoes my initial reaction:

Why not release std-toast (and other elements in development) as libraries first?

It turns out that std-toast and other in-browser web components are part of an idea called layered APIs. In theory this is an initiative in the spirit of the extensible web manifesto.

The extensible web movement focused on exposing low-level APIs to developers: the fetch API, the cache API, custom elements, Houdini, and all of those other building blocks. Layered APIs, on the other hand, focuses on high-level features …like, say, an HTML element for displaying “toast” notifications.

Layered APIs is an interesting idea, but I’m worried that it could be used to circumvent discussion between implementers. It’s a route to unilaterally creating new browser features first and standardising after the fact. I know that’s how many features already end up in browsers, but I think that the sooner that authors, implementers, and standards bodies get a say, the better.

I certainly don’t think this is a good look for Google given the debacle of AMP’s “my way or the highway” rollout. I know that’s a completely different team, but the external perception of Google amongst developers has been damaged by the AMP project’s anti-competitive abuse of Google’s power in search.

Right now, a lot of people are jumpy about Microsoft’s move to Chromium for Edge. My friends at Microsoft have been reassuring me that while it’s always a shame to reduce browser engine diversity, this could actually be a good thing for the standards process: Microsoft could theoretically keep Google in check when it comes to what features are introduced to the Chromium engine.

But that only works if there is some kind of standards process. Layered APIs in general—and std-toast in particular—hint at a future where a single browser vendor can plough ahead on their own. I sincerely hope that’s a misreading of the situation and that this has all been an exercise in miscommunication and misunderstanding.

Like Dave Cramer says:

I hear a lot about how anyone can contribute to the web platform. We’ve all heard the preaching about incubation, the Extensible Web, working in public, paving the cowpaths, and so on. But to an outside observer this feels like Google making all the decisions, in private, and then asking for public comment after the feature has been designed.

Have you published a response to this? :

Responses

Ethan Marcotte

“…the external perception of Google amongst developers has been damaged by the AMP project’s anti-competitive abuse of Google’s power in search.” @adactio on that toast brouhaha, and on Google’s power problem: adactio.com/journal/15357

Matthew Phillips

It’s weird to me that Google is accused of steamrolling standards by being open, while Apple literally ships new features unannounced and without discussion at all like it did with dark mode, and I see no hubbub about that.

Surma

A good big-picture write-up on the whole <std-toast> thing by @adactio. Not only a pretty accurate representation of our intentions, but also of the problems and mistakes we made. adactio.com/journal/15357

# Posted by Surma on Thursday, June 20th, 2019 at 8:43am

Arthur Stolyar

Also ApplePay instead of Payment Request at the time. Force touch events. Touch events back then. Whatever else proprietary behaviour like iframes. Other random vendor features.

Jeremy Keith

I 100% agree that Apple are the worst at making up proprietary crap behind closed doors. That in no way absolves other browser vendors from being held to account (especially the browser with the largest market share). adactio.com/notes/15359

Jeremy Keith

I 100% agree that Apple are the worst at making up proprietary crap behind closed doors. That in no way absolves other browser vendors from being held to account (especially the browser with the largest market share). adactio.com/notes/15359

Matthew Phillips

Held accountable for what exactly? I agree that “intent to implement” is poorly named. Is that it?

вкαя∂εℓℓ

I spent significant time last week articulating a lot of the same things and was hoping someone would - glad it turned out to be @adactio actualy. Thanks for writing up/explaining this nuance. I would characterize a couple of things slighly diff probably, but prob always true.

Friday Front-End

Toast: “Shockwaves rippled across the standards community when it appeared that Google Chrome was unilaterally implementing a new element called toast. It turns out that’s not the case, but the confusion is understandable.” by @adactio adactio.com/journal/15357

2 Shares

# Shared by Gunnar Bittersmann on Wednesday, June 19th, 2019 at 4:50pm

# Shared by Hugh Isaacs II on Thursday, June 20th, 2019 at 12:39am

1 Like

# Liked by Chris on Wednesday, June 19th, 2019 at 5:56pm

2 Bookmarks

# Bookmarked by Charlie Owen on Thursday, June 20th, 2019 at 2:03pm

# Bookmarked by Chris Aldrich on Thursday, June 20th, 2019 at 5:07pm