Introducing the new HTML element - welcome <clippy>!
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.
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.)
C says:
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.
"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.
As for putting
<clippy>and<toast>into browser, instead of JS library...I think we may add waaay too many elements this way.
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.
Zack B. says:
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!
BTreeHugger says:
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).
OK Google says:
Dan says:
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”
Chris says:
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.
CMZ says:
Scraping Burned Toast said on :
| Reply to original comment on