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.

Backlash

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.

Optics

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.

Wrap-up

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.

Update: 17 December 2019

If you came here from this tweet…

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:

  1. 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;
  2. 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.

Hello. Hello. Hello. This is the Vanilla JavaScript podcast. I’m Chris Ferdinandi, thanks so much for joining me, and I hope your 2020 is off to a great start. This is the first show of the new year. And today I wanted to talk about how HTML is a living language. Back in mid December, so a few weeks ago now, Alex Russell tweeted HTML may be a dead language because those who claim to love it can’t [00:00:30] imagine it being better. And today I wanted to talk about how just utterly, completely wrong Alex is. Not on everything, just on this particular sentiment. There are two points to Alex’s tweet and I think we need to kind of break them out and explore each of them separately. So the first is the idea that HTML is dead. And the second is that people who claim to love HTML don’t want it to change. Neither of those statements are true.

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 <nav> and <article> and <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 <audio> element to stream episodes and it is so damn easy to use. Several years ago stuff like that required these complex JavaScript and Flash plugins. It was so much work, and now native elements make it really, really easy. We get native responsive images with <picture> element and srcset attributes. We can asynchronously load JavaScript files with async or 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.

Most recently we’re now working on a new lazy loading attribute for images and iframes that will let you natively lazy load stuff without a JavaScript plugin. Jen Simmons explains in this really great video that I will also link to in the show notes, adding height and width attributes to your images, now reserve space for that image while loading and maintains aspect ratio. So you don’t end up with that jump [00:02:30] with the content when the image finally shows up. You’ve probably seen this before. A page loads, you’re waiting for an image, the image shows up and then suddenly the content gets pushed down. No more, with this new aspect ratio feature that’s coming. And there are plenty of new things that I would love to see added to HTML and CSS and JavaScript, but I don’t see how you can look at all this awesome stuff we’ve gotten and conclude that HTML [00:03:00] is dead.

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 <details> and <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.

If you’re newer to web development, [00:05:00] you may not know what the web was like before web standards. In short, it was fucking awful. Browser makers would just go off and do whatever the hell they wanted, creating new elements and new JavaScript methods and so on, to accomplish things that their users were asking for. It sounds good, but because each browser did things a little bit differently, writing code that worked everywhere was a fucking nightmare. Some people would use user agent sniffing to serve up different pages to different browsers. JavaScript files were littered with conditional if/else [00:05:30] statements using different methods for different browsers. It sucked. The web standards process ensures that this doesn’t happen again. It makes your life as a developer easier. I tweeted a little bit about this and Jon Lunman shared a really nice abridged history of the Browser Wars that I thought did a great job of summarizing what it was like and why standards matter. And he let me pull his series of tweets together into a summary that I will link to [00:06:00] down on the show notes as well.

Jon wrote in the early years of IE, Microsoft really pushed the boundaries of what could be done with JavaScript. They called it DHTML. It’s why so many enterprise/intranet systems were built for IE. No other browser at the time came close to offering the same native-like experience that we all take for granted today. Microsoft didn’t wait around for standards to emerge around this stuff, they invented whatever API they wanted, [00:06:30] CSS stuff too. Heck, they basically invented web components which they call DHTML behaviors all the way back in ’95. This meant a ton of rich dynamic web apps only worked in IE. But everyone used windows so everyone had IE, right? No big deal. Competing browsers gradually caught up in capabilities, but rallied around standards that different significantly from Microsoft’s made-up specs. By then there was a decade worth of enterprise [00:07:00] web apps in production that were built for IE only and it would be too expensive to rewrite or replace for modern 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.

That’s it for today. If you want to finally master JavaScript, head [00:10:30] on over to VanillaJSGuides.com and check out my pocket guides and video courses. They’re short, focused and made for beginners, and you’ll learn the ins and outs of a topic in under an hour. As a listener of this show, you can take 30% off with the code podcast at checkout. See you next time. Cheers.

10 Comments

Reply

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.

Reply

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.

Reply

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.

Reply

Does the headline for the last update have an incorrect date, or did you include a tweet from the future last week?

Martin Flodin; . Permalink
In response to Martin Flodin. Reply

Oops. Thanks. I have updated to be next week’s previous week.

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.