For those too young to remember, the Browser Wars entailed a tech rush by, among others, Netscape and Microsoft, resulting in useless features being implemented because they were fast to bolt-on, and useful features being rushed because they were hard. After the Browser Wars, the internet entered an era of stability as the last vestiges of the old web were mercilessly hunted down and destroyed by Google.
Chrome and Chromium-based browsers have the vast majority of the market share, and with the new version of Edge being based on Chromium, only Firefox is truly left to compete. We’re already seeing the effects of this, and they’re not ideal.
Get ready, this one is going to have a lot of links, and they’re important…
The Saga of <std-toast>
On June 12th, 2019, Google developers asked for a review of a proposed new element for HTML. Specifically, they asked the Web Platform Incubator Community Group (WICG), a community dedicated to fostering open discussion about the future of the Internet as a platform. It’s run by the W3C, and generally, it’s exactly where you should be asking about potential changes to the actual foundation of the Internet.
On the same day, however, they announced their intent to include the element in the Blink rendering engine. Now, that doesn’t mean it’s going to happen any time soon, but it caused some significant consternation.
The Basic Idea
Well first, let’s talk about the element itself. It’s a pop-up notification. Literally, it’s a notification that pops up from the bottom of your screen, like toast… from a toaster, or from the top, like toast from an upside-down toaster [feel free to insert a joke about Australia here].
This notification element can show up and disappear on its own (the term used is “auto-expiring”, or it can require interaction to send it away. It’s basically an HTML element devoted just to “we use cookies” notifications.
The basic HTML could be written like one of the following examples:
<std-toast>Hello world!</std-toast>
<std-toast><p>Hello world!</p></std-toast>
<std-toast> <p>Hello world!</p> <button>Click me!</button> </std-toast>
<std-toast> <p>Hello world!</p> <a href="https://example.com/" target="_blank">Click me!</button> </std-toast>
The Problems with <std-toast>
I mean… besides the unfortunate acronym at the beginning of the tag? And the problem that actual toasters are not, in fact, a universal metaphor in Internet-having countries, as pointed out by the ever-brilliant Jen Simmons?
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.
Ignoring those issues, it still requires JavaScript to work properly at all.
It’s additionally galling that toast is fundamentally an ephemeral UI element that is apart from page layout, and can’t work without JavaScript. Is there any other html element with those semantics? It’s a really odd precedent.
An HTML element that requires JavaScript. I’ll say it one more time for the Google devs at the back: JavaScript breaks, and it breaks a lot more often than plain HTML/CSS.
Then, it’s just gimmicky as hell. I mean, it’s something that we can already make with existing technology, and implementing it into HTML doesn’t actually make it that much easier. Nor is it particularly useful outside of a very narrow use-case. All it does is make the web’s underlying technologies “more like apps”, and while that’s not strictly a bad thing, is that really all we want for the Internet?
<toast> makes no sense to me. It reminds me of <marquee>, <blink>, and all the other gimmicky tags from before we figured we should separate styling, behavior and markup.
An additional point: even marquee and blink didn’t need JavaScript to just work. They were awful in so many ways, but they ‘worked’ on their own.
The Development and Review Process
One common perception is that a couple of employees at Google had this idea, and decided to just throw it into their browser engine, figuring that everyone else would just go with it. As previously mentioned, the whole situation is highly reminiscent of the browser wars, when browser vendors came up with gimmicky proprietary elements in an effort to compete.
Timeline: initial commit to personal repo: May 24 comment by an editor of WHATWG HTML (also a Google employee): May 28 Intent to implement email: June 12 Request for TAG review: June 12 First mention in WICG: June 12
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]”.
This has understandably upset people who very strongly believe in a community-driven approach to developing technologies as basic and open as HTML.
One of the benefits of standardization through W3C Working Groups is diversity of input. W3C requires the consideration of all feedback, requires consensus to move forward. The diversity of vendor perspectives considered matters, because different vendors have different values.
There is a process. It’s quite formal and clear. It’s not new. It’s not a matter of personal preference, nor a “misunderstanding”. Not a “you say tomato I say tomato”.
https://www.w3.org/2005/10/Process-20051014/tr.html#cfi
Think of all the many HTML elements that were considered and rejected over the years — and we are supposed to be on-board with TOAST? Because a couple guys at Google decided they want it. And they can. So no to <footnote> <author> <publication-date> But yes to <toast> ???
Even people who generally like and support the idea of the std-toast element are unhappy with how it was presented to the community:
Look, I get the “Move fast! Break things!” attitude. And I think it is exactly right that Google should experiment with the web. We all should! And, again, I think that <toast> is probably a useful addition to HTML.
But the way Google has gone about introducing it to the world betrays a huge lack of empathy for the poor sods who have review standards, for other browsers, for users, and for the broader Web community.
The Implications
Despite everything shady Google has ever pulled [please don’t kill our PageRank, thanks!], I’d honestly like to believe that this was the mistake of a few, rather than the beginning of Google dictating the direction of web design and development as a whole. But if it is, we have a whole new problem on our hands.
Google’s priority has been, is, and always will be making loads of money. And who can blame them? But if we don’t have competition between, not just browsers, but browser rendering engines, then a couple of random people at Google who haven’t necessarily thought things through will be able to drastically change the direction of the web pretty much whenever they like.
Look, I still generally like the things Google makes, but let’s be real: they don’t always make the best decisions. I could make a joke about Google+, here, or the even more ill-fated Google Buzz, but let’s have a look at a something that more directly impacts web designers and developers:
If Google were in charge of the Web Platform, we would not have CSS Grid Layout. With the personal exception of @tabatkins, Google did not believe in CSS Grid. Microsoft and Mozilla implemented their own, but it was Bloomberg who funded @igalia to code Blink’s implementation.
Featured image via DepositPhotos.
p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}
