Hacker News Reader

Comment by nwh | Hacker News Reader

I'm expecting "this email designed for gmail" badges soon.

The feature appears to be independently implementable in other clients, so if it takes off and those badges start appearing, then other e-mail clients can follow.

And some "designed for gmail" badges may actually be a good thing — maybe that would force Microsoft to do something with grotesque HTML rendering in the latest Outlook.

MS uses the Word HTML engine in Outlook since Office 2007. As well, CSS (even inlined) support when viewing mail seems to be pretty bad.

http://en.wikipedia.org/wiki/Microsoft_Outlook#HTML_renderin...

Campaign Monitor has a pretty great table[1] describing what's supported where.

[1] http://www.campaignmonitor.com/css/

"This email best viewed in Chrome."

Both Microdata and JSON-LD are open formats.

As is HTML and it provides little benefits to a lot of ordinary people and a lot to a lot of rogues.

The fact that it is open does not imply it needs either to be supported (does gmail support S/MIME, by the way?) or that it is convenient.

... HTML? You're joking, right?

Not that I know of. Why?

Links? Phishing would be much different if people read links instead of the <a> label.

Images? Really? Just attach them and do not add clutter to the message.

Edit: did I say something wrong?

Really?

There is a large disconnect between people that use/default HTML on in their mail clients, and people that don't.

Additionally, as always, people take it as an attack against themselves when you threaten an action they do often and like doing.

For my (probably our?) part, I prefer text email to a large degree. I do enjoy the ability to view in HTML a few select correspondences I get, but they could just as easily be links to a webpage. In a similar vein, I prefer bottom posting or inline replies for anything beyond a simple response, and trimming unused portions from large quoted sections.

People that reply with color coded text to denote who's speaking cause me a unique type of pain, and I reserve a unique type of hatred for them.

That said, there are probably others that I annoy with my style of correspondence.

> People that reply with color coded text to denote who's speaking cause me a unique type of pain

Not all of us do it on purpose, sometimes it's Outlook helpfully changing our text color to blue after we've copy/pasted from some text from a correspondent. I usually notice this right after I send. Sometimes if someone has a name that's unusual to me, you can tell I had to copy/paste it because it's blue and the rest is black. Always love that one.

A solution to this seems to be to set the default composition to plain text, which may or may not have other negative consequences depending on your usage. At least that's a solution in Thunderbird, I have no idea if Outlook handles this well (or at all), and any caveats it may have. I imagine it does handle it, Outlook has historically been pretty feature heavy and I know people would have asked for this.

I think he's referring to people who give no indications for who is being quoted/if the text is their response, /except/ different colors. Its pretty hard to do this without noticing - if you aren't seeing different colors, you should be adding (Tom) or whatever to mark who said what.

Sorry—I was reading into it as an analogy outside the context of e-mail: I initially interpreted it as a slight on the entire HTML technology. Making more sense now, sorry for the confusion!

I see and I understand. Not to worry. It looked lime some weird misunderstanding since the beginning.

The data format is open, but no other client will read and interpret these inbox actions

nothing stopping them from doing so.

Isn't that how most features are added? One client supports them and others follow?

The format may be open, the ability to use it isn't - you need to register with Google[1] or they won't display actions on your e-mail. This appears to be necessary for security reasons. Imagine if every e-mail provider did the same thing!

[1] https://developers.google.com/gmail/schemas/registering-with...

That's bad, yes, and I wish they didn't require that, but it doesn't hinder the use of the protocol outside of their services, which is the most important thing. It just adds some extra work to the senders.

To hinder: to add difficulty. I'd say it certainly does hinder use of the protocol.

"doesn't hinder the use of the protocol outside of their services"

> > it doesn't hinder the use of the protocol outside of their services

> To hinder: to add difficulty. I'd say it certainly does hinder use of the protocol.

How does Google requiring registration before actions are displayed in Google properties hinder use of the schemas in email outside of Google services?

Because just like google needs people to register for security, so do other providers.

This rapidly becomes unwieldy - how are you going to convince people to register with tons of providers? So this format is pretty much google only.

> Because just like google needs people to register for security, so do other providers.

That's probably a bad assumption, once you have more than a few parties using this system. I'd be surprised if even Google used the current, apparently manually-reviewed, registration system for long rather than as a short-term measure before moving to a less cumbersome accountability mechanism (and this is more "accountability" than "security".) But even if multiple parties were using that kind of method, there's a clear incentive -- especially for the players that aren't Google, but even Google has some incentive -- to build a facility where a shared registration application can be automatically distributed to multiple parties.

I assumed by "outside of their services" you meant non-google people who want to send email using this. On re-read, you mean it doesn't stop anyone else building a client that can understand these actions, right? That's true.

And even if they implement the "open standard" in outlook, who says Google won't bait and switch (oh the irony) then, like they did with their youtube apps on windows mobile?

Give me a break. How is requesting they remove a non-compliant youtube app a "bait and switch". Is this going to be the new "cool" thing to post now every time a submission involves google?

Oh yeah, bait and switch. If Google abused an API and went against the terms would you complain about bait and switch when the access was disabled?

So, suppose that (a) companies start sending useful metadata with their emails, (b) other clients like Outlook add support, and then (c) GMail capriciously removes support. As long as the metadata keeps getting sent, and there are clients which can do interesting things with it, I don't see the problem here.

As a vendor, the registration would be extremely annoying. Since these widgets are meant to replace HTML links and buttons, I would then have to create and support 2 versions: the fancy widget version all the providers I registered with, and a fallback for providers that don't support it.

Reply on news.ycombinator.com