This is a bad thing. Gmail needs to be e-mail and nothing more or this is EEE.
You know, people who use serious email, not to send pictures of balloons and 96-pt Happy Birthday in pink on purple text.
Meanwhile, my work e-mail account is fairly busy, pretty much all HTML, and I haven't seen balloons, 96-pt text, or purple background. (I do occasionally send pink text, though. I'm that person)
And all of these markup items are highly welcome. I'd rather live in the 21st century. (Although I would kill for procmail, but we can't win them all)
Why not? If anything, this should been a boon for us text-only client users, since the metadata is structured in a format that can be easily parsed and displayed in an appropriate way, instead of having to deal with HTML conversions.
Having a key shortcut on Alpine to activate the main email action, instead of having to cycle over the various links, sounds great to me.
Many high profile websites don't even bother sending a text/plain alternative with their emails anymore and the HTML is often cryptic when viewed from a text browser. Anything that can improve this is a good thing.
I do have a minor beef with this implementation however: at first I assumed that this metadata would be stored in custom email header (X-Mail-Action or whatever) but as far as I understand it's embedded in the HTML instead. It would make it more painful to add support for that to existing clients, especially if they use external tools to display HTML.
Now there's "Serious" email, and if you don't read your email on the cli, you're just an amateur easily impressed by shiny toys.
Can't make this stuff up... Or, you know, that structured data and semantic markup are excellent for any number of "advanced" uses.
Once the big players start adding custom features on top of existing protocols we start seeing fragmentation and parts of the market being cornered off. Once people start depending on this custom functionality, the vendor usually starts raising the walls to lock people in (see GTalk -> Hangouts.)
The spec is schema.org, which is a format defined by multiple parties, not just Google: https://en.wikipedia.org/wiki/Schema.org
And it's encoded using JSON-LD, which is also not a Google creation, and it's standardized by the W3C.
[0]: https://developers.google.com/search/docs/guides/intro-struc...
That's not my definition of open. My definition open is you can access the spec for free without limitation, and use, modify, and redistribute it as you see fit.
If I am feeling grandiose I will concede that openness requires not just access, but easy access and usability by all stakeholders. That's a little radical, but the point is just that there's a degree of accessibility implied in the above. If you have to crawl through a snake pit to get the source perhaps that's not really open.
But your definition, which requires buy-in from Oracle and PepsiCo in order to be "open"... I think I reject that definition.
The standard is http://json-ld.org plus https://schema.org. Client developers could freely implement it. It's a W3C standard. But don't modify it just because you can – standards don't like that.
It's annoying that google doesn't activate it for everyone, but that's like complaining about browsers allowing adblockers or SSL root certificates being tied to requirements.
That's not the 'open' part. That's the 'standard' part, where a broad consensus of all stakeholders is what ensures that it's not a mere thought experiment that lacks adoption.
Why send the rest of the ecosystem scurrying about, chasing their tails?
And if the ecosystem gets the rug abruptly pulled out from under it one time, then how many more times will their efforts get trashed? Probably as many times as is necessary to shake them loose.
No announcements, no roadmap, no communication channel, just a sudden upgrade and everything starts timing out, or throwing errors.
Someone threw the killswitch. And they'll toggle it as often as needed, to cut out whatever the target percentage of attrition is.
That's not quite true.
Google Talk is still available, and you can use that in place of Hangouts, and you can use third-party clients with it.
However, you cannot use third-party clients for group chats, and you cannot speak to users on other XMPP servers (there is no true federation).
This is how innovation happens. If the experiment shows promise, it gains adoption by other vendors. This is basically how every browser advancement in the last 10 years (or more) has come around.
This is already happening. Try writing html email that looks good on all email clients and witness the horrors
The only danger is that some proprietary service sucks it all up.
You know, incompatible with anything else, with not even API access, no third party clients and Facebook as the ultimate arbitrator of your ability to reach anyone (including your customers).
Besides, what is wrong with HTML? And why doesn't it render properly in the gmail client?
This way they can use a more data-friendly format created and supported by multiple organizations (Schema.org), which any client can use freely.
As a non-Gmail user myself, I'm quite happy with their choice, since it means I can make it work with my client and my calendaring software.