I find myself in a tempest in a toaster. Yesterday I (and much of the web standards world) learned about two possible new HTML elements proposed by Google, std-toast and std-switch. I had no idea what “toast” meant in the context of the web, a problem shared my many other people. It turns out it’s a UI pattern, those little notices that pop up and then disappear without user interaction.
But wow, new HTML elements! This is the holy grail. In my part of the web we don’t even dream about new HTML elements. Oh, we’ve tried, but Hixie didn’t much care for footnote, WICG didn’t much care for list titles, and no one much cared about author. Just last week the author of the extensible web manifesto warned me to never expect new HTML elements, due to the difficulty of changing the parser.
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. My first tweet about this yesterday sums up my initial reaction:
<std-toast> and <std-switch> feel like a new approach to standardization, as does requesting TAG review on the same day you post an intent to implement.
Let’s look at the timeline for <std-toast>:
- Initial commit to personal repo: May 24
- Comment by an editor of the HTML specification (also a Google employee): May 28
- Intent to implement email to blink-dev: June 12
- W3C TAG review requested: June 12
- First mention in WICG: June 12
- Issue filed in HTML spec: not yet
Several Google employees have told me that this is fine, that their process is working as intended. They describe this as seeking early feedback from the community. But they didn’t even follow their own process. The template for the intent to implement email says:
Link to explainer. You should have at least an explainer in hand and have discussed the API on a public forum with other browser vendors or standards bodies before sending an intent to implement. If your change is not yet at this stage of maturity, feel free to solicit feedback informally on blink-dev instead.
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. Is a new HTML element the best solution for whatever problem <std-toast> is trying to solve? I have no idea, and Google is already so invested in this solution that they are telling the world they will be writing code.
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.
Getting feedback from outside your own company is not just idealism. Jen Simmon’s first reaction to the name std-toast was concern about how that would work for people who don’t speak English as a first language. On Twitter people are wondering about what looks like Custom Elements becoming full-fledged elements, the need for JavaScript to use these elements at all, etc. Are we enshrining current patterns in UI design into HTML forever?
I am a member of the CSS Working Group. We talk about new ideas in public. Alternative solutions are considered long before there are intents to implement. We get valuable contributions from every browser vendor, from people in other industries, from people who have to teach developers about new features, from people outside the working group. We need all the help we can get; we welcome feedback at all stages. I hope Google can see the value of working with the larger web community before features are designed, as well as throughout the process.
Dave Cramer works for the book publisher Hachette, edits the EPUB spec, and is lucky to be small part of the CSS Working Group. He notes that toast is illegal in Belgium.
std-toast sounds like a toast that has an STD 👎