Scraping Burned Toast
Google engineers have proposed a new HTML element,
<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:
I believe new HTML elements should go through a standards process, be debated by multiple parties (not one), be useful to most websites (pave the cowpaths), and be written in language that makes sense for HTML, especially for folks who don’t speak English well.
So no on this. twitter.com/stevefaulkner/status/1138…
Web standardization according to Google? "Nobody outside my team has reviewed or approved of the explainer in my private repo, but if we implement and encourage devs to use it, surely our competitors will agree to implement it [because our market dominance determines compat]". twitter.com/dauwhe/status/1138…
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.
Been on the web for a long time, but today was the first time I heard there was such a thing called toast component and there was a newly proposed <toast> element for it. After doing some research, I am disappointed to learn it has nothing to do with website screensavers. pic.twitter.com/gUMVLjM2Ty
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
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
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:
"intent to implement" means that someone *wants* to implement something behind a flag. It does not mean that the thing was already implemented. It certainly doesn't mean that it shipped. It's an "FYI – I want to play around with X"
One of the things that's different about how we operate in Chromium vs. other engines is that we force our teams to work in public and ask for feedback as early as plausible.
"Intent to Implement" is many, many miles away from shipping on-by-default to Stable in our process. twitter.com/slightlylate/status/1139…
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.
The toughest thing about contributing to standards on your own time is that a team of people funded by a corporate behemoth will outpace you.
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.
Update: 17 December 2019
If you came here from this tweet…
I think when you present something as well-researched as github.com/jackbsteinberg/std-toast… and get adrianroselli.com/2019/06/scraping-burned… in response, browser vendors are going to be very hesitant to invest any time in the controls listed in the OP of this thread.
It implies that I single-handedly killed
<[std-]toast>. I didn’t even know it was dead, though it is clearly abandoned. Anyway, to address two specific points:
- It was not well-researched. No work was done to look at the accessibility of the patterns in frameworks (the OP acknowledged it), the supposed screen reader tests never came out, and it looked only at libraries as opposed to including design systems;
- Further tweets in the thread from Google employees suggest the feedback was toxic, though they may have been referring to tweets and posts from others. Regardless, you have this post (which shows my frustration), my tweets, and my issues on the repo to look at to decide if I was being toxic.
Google folks acknowledge that its language,
intent to implement, led to much of the initial reaction online (see parts of this post above and comments below). They are changing that process, even if it’s clear some feel the blame falls squarely on everyone else for not learning Google’s own process.
Regardless, I suppose your take on this depends on whether you feel I, a random guy on the web, could bring Google to a halt when it controls most of the standards process and browser share, or you suspect Google just realized the requirements were poorly specified and far more effort would be needed to define the element in an accessible way.
Maybe that is why
<dialog> is such a mess — getting the accessibility right is hard, and browsers seem less interested in sorting that before making more ephemeral messaging elements.
Update: 8 January 2020
Chris Ferdinandi mentioned this post yesterday in a Vanilla JS podcast episode, HTML is a living language.
Episode transcript with time-stamps every 30 seconds.
So let’s dig in. [00:01:00] The first, HTML is not dead. Over the last few years, HTML has added a ton of awesome new features. First HTML5 brought us semantic elements like
<header>. We have browser native date pickers and special input types that handle form validation and pull up custom keyboards for email addresses and URLs. We also picked up browser-native ways to play video and audio files, things that used to require Flash. The website for this podcast [00:01:30] uses the
<picture> element and
defer and pre-load important content with
rel="preload" attribute, and I’ll link to all this stuff [00:02:00] down in the show notes.
The other piece here is that you can love HTML and still want it to get better. The idea that people who claim to love the web can’t imagine it being better is just patently false. Recently, Dave Rupert documented how
<summary> elements are not actually an accordion even though they behave that way, and that this subverts expectations and makes his job harder. Scott O’Hara has written before about the
<dialog> element, which functions kind [00:03:30] of like a modal, misses the mark in many ways and is not accessible by default out of the box. There’s a lot of stuff he needs to do to it to make it work the way it should have. In Dave’s article he even suggested new elements that he’d love to see exist, like accordion, tabs, drop-down, and tool-tip. I was chatting about this a little bit with Mandy Michael and she suggested a
<carousel> element would be another awesome addition. And I think these are all things that are hard to do well and would benefit from built-in elements.
We spend [00:04:00] so much time on these low level features and I think what a lot of developers need are simple ways to do accessible things that are currently hard. So that’s one piece of it. The other thing here is that there’s a bit of a political backdrop to Alex’s tweet. It included a link to an article from Adrian Roselli that criticizes how Google Chrome hastily rolled out the
<toast> element without going through [00:04:30] the proper standards process. And I will link to Adrian’s article in the show notes. Web standards are a set of processes that browser vendors are supposed to go through before implementing a feature to get other browser makers on board, document specs and iron out details. They exist to make sure that whatever you ultimately ship will be as useful as possible to as many people as possible and will be implemented consistently by all browsers.
Many of these legacy systems are still in use today, which means many organizations still need IE in order to use them, which is why Microsoft can’t just kill it already despite desperately wanting to. And that’s one of the reasons so many of us still have to make our shiny new modern web apps also work in crappy old IE. We all want the web to evolve and get better, but if Google takes [00:07:30] matters into their own hands and adds nonstandard features to Chrome, then Chrome risks becoming the new IE6. So that was Jon. If it wasn’t obvious already from his last statement, this is why web standards matter and the Google Chrome team’s position that standards process is too slow is so dangerous to the web. I’d actually argue that as the dominant browser on the web, Chrome is already the new IE. They are not at risk of becoming [00:08:00] the new IE, they’re already the new IE, just by virtue of being the browser that most people use. And the question is will they learn from IE’s mistakes or are they doomed to repeat them?
Chrome has more developer advocates than some browser vendors have employees. And their approach to web standards is often, “We have an idea, let’s just throw it in the browser behind a flag and see what developers do with it.” And while that sounds reasonable on the surface, it’s behind [00:08:30] a flag after all, it means that Google never gets feedback from other browser vendors on what it is, how it should work or in the case of the ill-named
<toast> element, what it should be called. And when Google does things like this, they put Firefox, Safari and other browser vendors in an awkward spot. Do they ignore the element and they get accused of not innovating? Do they push things through even when they have issues and reinforce to Google that it’s okay to just ignore the web standards process?
On mobile devices, a [00:09:00] majority of web usage happens in apps. To some people that means that the web as a platform is dying and it’s not a link to my kind of rant on that in the show notes, but the thinking here is that it can’t compete with native app features. A segment of people truly believe that in order to keep up, browser features need to grow rapidly to match the feature sets that are available in native apps. And I think that’s a false dichotomy. I don’t think this is a zero-sum game. The choice isn’t [00:09:30] web or apps, and one doing well doesn’t mean that the other is losing.
On desktop, we use browsers and native apps alongside each other comfortably all day long. No one thinks this is weird. But on mobile, it’s this big battle for the platform, and I don’t really understand why. On my phone there are some things I’d rather use an app for — email or streaming music. For others, I’d rather use a browser. I don’t think [00:10:00] that the overhead of another app is always worth the benefit. There’s some things I’d rather have a browser for. And I don’t really get why this is a bad thing. So no, HTML is not dead. The web isn’t dead. They’re changing and they’re growing slowly, deliberately slowly towards a wonderful future.
Update: 20 January 2020
Offering my feedback on
<std-toast> required a good deal of research and notes to make sure what I said was technically correct (the best kind of correct).
I gathered all of that together and wrote Defining ‘Toast’ Messages, where I outline appropriate ARIA roles, applicable WCAG Success Criteria, and offer some alternatives.
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
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…)
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?
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.
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?…
<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.
Does the headline for the last update have an incorrect date, or did you include a tweet from the future last week?
Oops. Thanks. I have updated to be next week’s previous week.