Scraping Burned Toast

Poached eggs, soy sauce and white pepper with slices of toast slathered in kaya jam for dipping. On the mug is Billy Gregory’s 2015 #SUX tweet.

Google engineers have proposed a new HTML element, <toast> or <std-toast>, that is a container for presenting brief or simple notifications to users.

But of course it is not quite that straightforward.


It is going to be impossible to extricate this proposal from the reactions it has garnered. So let’s look at those first. A couple examples from Twitter:

Terence Eden responded with parody:

Me and my colleagues at Microsoft have decided that the world needs more Clippy – the adorable animated paperclip. To help with that, we’re bringing a new feature to Edge 6.0.

Web Developers can now use <clippy> to call up an animated virtual assistant.

Confusion over the term toast has been a common complaint over the last couple days.

The timeline has alarmed a few people, particularly when it feels far more accelerated than any other addition to HTML has been.

Let’s look at the timeline for <std-toast>:

  1. Initial commit to personal repo: May 24
  2. Comment by an editor of the HTML specification (also a Google employee): May 28
  3. Intent to implement email to blink-dev: June 12
  4. W3C TAG review requested: June 12
  5. First mention in WICG: June 12
  6. Issue filed in HTML spec: not yet

Google folks were quick to jump to Google’s defense, asserting that the TAG wants to be notified this early in a process, and that intent to implement does not mean it is getting stuffed in a browser.

The heads-up on Discourse was just a heads-up, essentially moving all conversation to GitHub. Conversation can (and will) happen on Discourse, but by declaring it has been submitted to the TAG and there is intent to implement, people are moving to the venue where they feel it will actually play out.

But for those of us who watched the <picture> element go through a community-driven standardization process (even running a crowd funding campaign to pay someone to work on it), this all seems very… wrong.

The Genuine Need

Interestingly, and probably unintentionally, Google has stumbled on a documented gap in HTML. I do not believe they knew about it, since the research provided on GitHub only discusses how libraries and frameworks implement a visible message box.

ARIA 1.2 contains roles that do not have native HTML counterparts, as outlined in 2.14 Aria roles and properties not available as features in HTML. The roles that appear to most closely match this proposal:

Note that none of these roles talks about how it should look, but instead how each functions and exposes itself to accessibility APIs. I added this as an issue on the <std-toast> repo.

Not only does the research document not reference these existing vetted patterns possibly in need of native HTML elements, people are trying to identify the types of these things and are still unable to create a definition that does not anchor on visual display. Even the provided examples fail to be consistently accessible (if at all).

In a nod to how this entire proposal is about appearance instead of creating an inclusive HTML feature, even the table tracking different libraries is a mess of emoji (never mind that GitHub itself hobbles tables with display styles that nobody ever tested with a screen reader)

It is clear there is plenty of work to be done (on the proposal itself as well as the concept) before it meets the bar of inclusion in HTML, no matter whether WHATWG or W3C is running it.


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.

Some Googlers did their best to explain their definition of “intent to implement”, clearly recognizing that term alone was causing a lot of reaction:

Anybody at Google who does not understand these optics is perhaps too ensconced in their own processes to recognize how this looks from the outside. The good news is that some folks are at least asking questions internally.

None of this, however, addresses the overall perception that with WHATWG now moving to own the HTML standard of record, with WHATWG’s representation from Google, and with a de facto browser monoculture, people outside Google and Chrome generally feel they have no voice.


I have a day job (and more). I do not have time to contribute much to the standards process. I do not monitor channels. Every time I weigh in on one of these things that is time I am not being billable, not putting food on my table. I cannot keep up with a team of Googlers whose job description includes this work.

What I can do is advocate for accessibility and draw a line where I will withdraw my support. For as long as this moves the documented roles in ARIA forward then I will do what I can to help. The moment this becomes nothing more than vanity, a feature for AMP, a developer-only addition, or is just for some users, I will advocate for this to be killed on the spot.

Update: 19 June 2019

Jeremy Keith has gathered some of this all together in his post Toast and includes this paraphrased nugget from a Microsoftie about dumping Edge:

Microsoft could theoretically keep Google in check when it comes to what features are introduced to the Chromium engine.

I suppose it helps that Google has no idea how to fork an engine. Oh. Right.

Update: 10 July 2019

Scott O’Hara may have dealt a one-two punch to <[std-]toast>, if I may be so bold to make the prediction.

In his post A toast to an accessible toast…, Scott outlines UX considerations for an inclusive toast. He leans on WCAG, best practices, and known issues. Overall, this seems to cover issues never considered in the original <[std-]toast> proposal from Google.

In his follow-up post, <output>: HTML’s native live region element, he reminds us that HTML may already have a native element that does most of what the proposed <[std-]toast> does (at least what it should do). With some CSS, scripting, and browser fixes it may be the native element that makes <[std-]toast> unnecessary. It also demonstrates how even Google’s own browser struggles to get the basic accessibility correct for an element that has been around for 10 years.



As one of the proposed name is a xxx-yyyy scheme, why didn’t they implemented it as a cross-site re-usable webcomponent ?

It is so simple, even with vanilla JS/CSS

In response to Da Scritch. Reply

A few others have wondered the same at the repo and on Discourse. In this case it looks like the team wants to make use of Layered APIs instead, which is apparently the new hotness.


Just wanted to point out that the person that was funded to work on the community-driven <picture> implementation and the person you’re quoting explaining the Blink process now are one and the same. (And it’s me. Hi! :D)

The process that is in place now is the same process that was in place when the picture implementation was underway. (e.g. here are a couple of intents to implement I sent back in the day for srcN and picture and srcset. One was more successful than the other…)

In response to Yoav Weiss. Reply

Hi, Yoav! I still have the shirt from that crowd-funding campaign. I am happy to say I still fit in it, too.

I intentionally did not draw that connection here, partly because I did not want to imply that I was making yet more comparisons to Googlers in the mix (as I think that was prior to your time at Google?).

Since you are here, do you think my assertions / conclusions about the optics are valid in any way?

In response to Adrian Roselli. Reply

Hi Adrian! Glad to hear the t-shirt still fits :) (and yes, that was a few years before I joined Google)

Regarding your “optics” section:

I personally haven’t seen any heavy promotion of that proposal from Google folks (I first heard about it on Twitter)
I was one of the folks doing “damage control”, or in preferred terms, trying to explain where in our process that proposal was standing (e.g. extremely early)
AMP folks indeed expressed their support for the proposal. In my book, that doesn’t automatically means that it’s a bad one…

We’re now looking at renaming our intent process stages, as it seems like “implement” makes it so that people not familiar with the process think it’s a later stage than it already is. Any other suggestions for process improvements will be welcome.

Otherwise, the last paragraph of that section saddens me, as it is far from being true.
I was a contributor to Chromium for ~6 years before eventually joining Google. During that time at no point did I feel that I have no voice, or that my opinion counts less because of my (lack of) affiliation. External contributions are extremely valued in the project, as well as in the spec world. And when it comes to new proposals, we are literally begging for developer and other browser vendors’ feedback on Discourse and on the various GitHub repos. So you really shouldn’t feel like you don’t have a voice.

In response to Yoav Weiss. Reply

Thanks, Yoav, I appreciate the time you took to respond.

FWIW, I feel I have a (small) voice. As evidenced by this conversation. What I do not have, however, is the time nor technical skill to contribute to all the places where I see help needed. It feels like Whac-A-Mole for me.


Would it be so terrible to extend the dialog element instead?…

In response to r0b. Reply

The <dialog> needs better support in browsers anyway, but <dialog> would only apply here if they want interactive children in the messages. If not, if the messages are only informational (and potentially dismissable), then a <dialog> is overkill. I go into more detail in issue 29: Avoid Interactive Children, so if you have thoughts then please leave some there. In short, not necessarily terrible, but not necessarily aligned with the proposal.

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.