Making a universal email message have bespoke instructions for a specific mail provider. Call me old fashioned but I don't like that. Infact I still like to read my e-mails in plain text.
Also, I dare say, not so useful for the many of us accessing gmail via Mac devices' mail clients.
> Making a universal email message have bespoke instructions for a specific mail provider. Call me old fashioned but I don't like that.
Its all using open standard formats, and the specific schemas are open standards or proposed for standardization (and Google has said that its schema support may change if the schemas change in the standardization process.) Other providers could use it as well. This is how progress happens in open systems. The alternative is either abandoning the open system for new functionality, or just never getting new functionality at all. And its not the provider that is key here, but the client (the fact that for many gmail users the supplier of both the mail service and the mail client is the same makes it easy to confuse the issue.)
> Also, I dare say, not so useful for the many of us accessing gmail via Mac devices' mail clients.
Yes, features in the Gmail client that aren't included in other clients aren't useful to people using the other clients. I'm not sure why this is noteworthy.
They may be open formats, but you can't just throw Microdata and JSON-LD into an email and expect Gmail to display your actions. You have to register with Google:
Implementation-specific email headers aren't new, and many providers have been leveraging them in one way or another -- probably since email itself came to be. Outlook is a great example here. It's basically just value-add's for the client.
You can still read email in any client, so why would you choose any specific client? I think the onus remains on the content creators, just as it is on the web and elsewhere on the net, that they only use the extended functionality to enhance the content (and not replace it). An example here would be HTML emails -- which, since you said you prefer plain text, I'm sure you hate? But they are common and those that use them know that they need to include a "view on the web" link for clients who don't understand HTML.
I do like plain text the best though, as I think that's where email excels, though SMS has some overlap. Ultrafunk Popcorn[1] was my preferred email client for 5+ years, and was an awesome client. Required only a conf file and something silly like 200k of RAM to run. Sadly, development stopped on it awhile back I think, though it probably still works just fine. It's the equivalent of the foobar2000 music player, dead simple and efficient.
Making a universal email message have bespoke instructions for a specific mail provider. Call me old fashioned but I don't like that. Infact I still like to read my e-mails in plain text.
Also, I dare say, not so useful for the many of us accessing gmail via Mac devices' mail clients.