Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Regarding 1. it's up to the client to parse and highlight links in plain text.

If the client is interpreting the content and then displaying its interpretation to the user, then it's not plain text anymore, is it? It's a format; in this case it's a poorly-specified, ad-hoc format and broken format[1] that is worse than simply having a reduced ad-hoc HTML format.

Just like HTML is "plain text" which is interpreted by the client and that interpretation is displayed to the user.

[1] For example, what if the sender types in `You should go to http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS!



> If the client is interpreting the content and then displaying its interpretation to the user, then it's not plain text anymore, is it?

Yes it is.

> It's a format

Yes, plain text is a format. The best format.

> in this case it's a poorly-specified, ad-hoc format and broken format[1] that is worse than simply having a reduced ad-hoc HTML format.

Well sure, plain text sucks at being HTML. That's because it isn't HTML; it's plain text. Plain text is not "poorly-specified, ad-hoc and broken" as plain text; only as HTML. The solution is not to use it as HTML.

> For example, what if the sender types in `You should go to http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS!

Ah, so that doesn't happen if the sender types in the wrong thing in HTML...?


>> For example, what if the sender types in `You should go to http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS!

> Ah, so that doesn't happen if the sender types in the wrong thing in HTML...?

I can't tell if you're being purposely contrarian or simply don't understand users.

The problem: Things that shouldn't be links get turned into links.

Your response: $SOME_OTHER_PROBLEM

I mean, really? You can't tell the difference between someone making a typo when intending to write a link and someone making a typo that results in a link?


So if you send that as text that isn't HTMLified by the recipient's client, they'll copy it as text and paste it into the adress line of the browser. The problem is still that the recipient goes to an adress the sender didn't intend (i.e. the recipient is stupid); has nothing to do with HTML vs text.

Or, if you want, the problem is that the recipient's client software HTMLifies text. Stupid client software (and possibly stupid recipient, for using the stupid software). Still has nothing to do with HTML vs text per se. Yes, that is literally $SOME_OTHER_PROBLEM. I mean, really? You can't tell the difference between various formats and problems caused by something else entirely?

(I get the feeling your supercilious "I mean, really?" was intended to slyly convey that I was the one being stupid here. IMO that backfired rather convincingly.)


I imagine example.com is either set up to be robust enough to withstand that, or they don't care if it goes down: https://www.iana.org/help/example-domains

Oh interesting, I pasted a URL in plain text and a bit of code in HN turned it into a link you can click on. I think it's totally fine for email clients to do that too.

The only thing I find redeeming about HTML email is the ability to have inline images so when I'm illustrating some sort of process to somebody I can do it more clearly. Without those, I'd create and send a proper document (I don't object to attachments), or publish the information on a wiki/blog/etc - but perhaps a those would be overall better approaches than a 'rich' email.


Fair, but url syntax is strictly defined in RFC 3986: https://datatracker.ietf.org/doc/html/rfc3986


What does that have to do with someone typing 'http://example.com' with the intention that that is not turned into a link?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: