Introducing the new HTML element - welcome <clippy>!
By @edent
· google HTML5 standards web · 15 comments · 700 words · read ~47,010 times.
Hello! It looks like you're writing a blog post - would you like help with that? chuckles
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.
I've spoken to several people in Microsoft, and we all agree it is a good idea.
We looked through a number of great software projects (mostly from Microsoft) and found lots of inconsistencies in the way Clippy is presented and invoked.
So I've written a spec for how I think it should work. I've not actually spoken to many other developers about what their user needs are. I'm pretty sure I'm representative of the majority viewpoint.
Because users keep buying and using our products, I'm going to assume they all love Clippy as much as I do. The little rascal! So, no need to waste time worrying about how users actually feel.
You can start using Clippy on your websites right now!
Fear not my friends! I don't work for MS and this isn't a real proposal. The above is a satirical look at the current state of web "standards" development.
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]". https://t.co/aeOCxhLulb
— fantasai (@fantasai) June 13, 2019
Google have decided the world needs a <toast> element. For the record - I think that's probably a great idea.
But my views don't matter much. They shouldn't matter much. I'm not the average user. I'm not representative of all developers.
The way Google has gone about this seems to be…
- Ooh! I have a cool idea!
- Other people in Google agree with me!
- Other Google projects could benefit from this?
- Let's stick it in Chrome!
- Oh, guess we should tell the community what we're doing.
(I'm deliberately simplifying and probably being a bit rude to the people behind this.)
Here's (my) idealised version of how a new element should be introduced:
- Have a cool idea
- Speak to real users and see if it meets a user need
- Publish the (vague) user research and start discussing with peers around the world
- Design and iterate based on feedback
- Test with users. Pass/Fail based on beta testing
- Publish test results
- Work with community to improve things
- Etc.
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.
It feels like a Google-designed, Google-approved, Google-benefiting idea which has been dumped onto the Web without any consideration for others.
I know that isn't the case. And I know how many dedicated people have worked hard on this proposal.
For old fart like me, this feels like the Microsoft Internet Explorer days. MS dumping features onto the web and everyone had to do what they say because they're the biggest kid in the playground.
I think the chaps at Google probably think they're the good guys. That they're doing the web a favour. That users love them.
They genuinely don't see that people feel they have to give in to Google's demands or face irrelevance.
To reiterate - I think <toast> is a good idea. But Google have presented it in such an arrogant way - and with no user research - that I'm getting afraid of what they'll do next.
It looks like you've finished writing this blog post. Would you like help publishing it?
(And, a special note for Geeks like me. All analogies break down eventually. They are a rhetorical device used to illustrate a problem space - not to fully map it out. Please don't let the inconsistencies of the analogy be the focus of your comments.)
Mastodon
Twitter
Facebook
LinkedIn
Reddit
HackerNews
Lobsters
Pocket
WhatsApp
Telegram
It’s easy to get caught up in a “good idea.” Software developers think of a lot of “good ideas” and some of them actually do turn out to be truly good ideas. But at least for me — and I suspect for others — it can take days, weeks, even years to look back at an idea and understand why everyone else wasn’t as enthusiastic about my idea as I was.
Occasionally at that point I’ll still think I’m correct and that my idea is good. Other times it’ll be clear it was a terrible idea and that’s fine too. But a lot of ideas just need to be exposed to the community for a good, long time before turning into action, and allow everyone time to think, discuss, and think again.
From the Intent to Implement:
"The interoperability risk comes from the potential that other browser vendors don't see the benefit of building this into the web platform. We hope that by implementing and iterating with web developer partners, we will be able to determine the value of this effort and make the benefit clearer."
Can't really argue with that, as it's how we've proceeded in the Maps for HTML Community Group, more or less, except minus the community.
We all have Custom Elements API, so we can use it: https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements
As for putting
<clippy>and<toast>into browser, instead of JS library...I think we may add waaay too many elements this way.
But is adding a lot of useful elements such a bad thing? The browser, being a way more efficiently coded application, would probably be a lot faster at handling the tag as well as displaying it along with the behavior and styles than a JS library.
Plus it can be easily designed by the browser's developer to fit a native look and feel. Also, if the tag is never used, little to no time is wasted on dealing with the tag especially comparable to handling it all in JS.
I don’t know if Chrome devs realize they’re doing Fire and Motion to other engines: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
They relentlessly keep adding more stuff, and won’t pause and think for a second, because Native will eat the Web if they even blink.
Then they say everyone else who doesn’t keep up just sucks. No time for shitty browsers lagging behind!
And every new tag, every new API gives them points in HTML5 tests, Chrome-only demos, conference talks, and excuses to block other browsers from Google properties (you get YouTube plain-text version, because you don’t support the polyshadowtaghint API added last Wednesday!)
So Safari spending a lot of effort on privacy doesn’t count. Needs more WebDojo instead!
Edge’s internationalization and accessibility was for nothing. Not flashy enough for a conference!
Firefox re-engineering CSS on the GPU doesn’t count. Should have added FramePortals instead!
The real concern here is that if Google dumps a proposed standard out there, and ships it broadly in Chrome by default (as they have for other standards they’ve wanted to push), then it will quickly become a de-facto standard and force its way into the standards regardless of how severe the problems with it might be.
We’ve seen how well that worked out in the past with stuff like touch events and Shadow DOM v0, and we don’t need to repeat that with “toast”, so it’s hardly surprising that folks get twitchy when they see Google doing something which indicates we will repeat that past yet again even more intensely with many multiple features (here’s looking at you, Project Fugu).
These days Google honestly seems more interested in shoving whatever they and a few other large companies want out into the web platform as quickly as possible in an 80% done form (if that), and then waiting for everyone else to do the really hard 20% of the work of de-Blinking and properly standardizing it over many months, while Google gets to act like heroes for “moving the web forward”.
Things wouldn’t be so scary if they never pushed out their draft implementations for broad public use until there was at least one other generally-interoperable implementation. But even if they have great individuals working for them who want that to be true, they’ve organizationally decided to be bullies instead, right down to how much of their own web services are “best in Chrome” (and almost never because Chrome is best, but because they design to Blink’s quirks and quirks of their draft spec implementations first, then maybe some day make a truly standards-compliant version).
I heard through the grapevine that a potential underlying reason for Google employees shipping new web features is that there is a personal financial incentive for it. I’m not sure if it just looks good on requests for promotions/raises or there is a specific bonus for just shipping a project but either way it’s harmful. I know in one case a Googler said they were going to ship a feature despite fundamental concerns with the API from other browsers because they had an OKR for that quarter to do so.
The naming of this element feels way too casual for a standard, as if the web is just entertainment.
Toast has meanings beyond “a Slice of bread common in US popped up in a top loaded toaster oven.
Apart from assuming every culture is familiar with it, it would be like naming all “save” functions as “floppy disk”
… is that really the origin of “toast” in a browsing context? I would have expected it to derive from toast in a gathering context (“a call to a gathering of people to raise their glasses and drink together in honor of a person or thing, or an instance of drinking in this way”) in that it’s an interruption of sorts.
Personally, I’m more worried that Google is going to try to slam some kind of default behavior onto that only really works for them that’s really difficult to circumvent. The casualness of the tag is, in my opinion, kind of irrelevant so long as it adequately describes the semantics. For example, I think that
<
aside> is pretty casual sounding, but it very accurately describes what the content is. In that vein, I would agree that is probably not the best choice; is probably better.
Google has become the Microsoft of the 90s and it many ways Microsoft is becoming the Google of the 90s. I mean, Microsoft never had Amnesty International make official complaints against it for human rights violations. Looks like Google dropped the unofficial “don’t be evil” mantra at just the right time. That company has seriously lost its way. It thinks it’s God’s gift to humanity and knows best for everyone, like all the worst qualities of an arrogant technologist.
I’ve been saying this for years and nobody cared to listen. Telling people, “Because you chose to give Google ALL of the power it’ll eventually become this behemoth you can’t get rid of and then you sort of just begrudgingly accept it.” “No way, Google is cool!!”
This Article was mentioned on adrianroselli.com
This Article was mentioned on lobste.rs