Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Caniemail.com – like caniuse but for email content

caniemail.com

Post reply on HN
Print view View original

241–250 of 263 posts

Re: Caniemail.com – like caniuse but for email content

#241

Post by HelmetFigNewton »

tuyiown wrote: post #146
HelmetFigNewton wrote: post #110

[flagged]

caniuse is an extremely popular website among people that had to touch web technologies, so much that almost anyone searching for issues on web apis seriously will have hard time not stumble upon it very quickly. Hence, it's a totally valid assomption that the HN crowd might be aware of it. I'm sorry you were not, but you really are an outlier on this, which is really not a bad thing, btw.

Thanks for the reply, but I've read HN almost daily for years and have been a professional developer for way longer than that. I also just finished an API-definition project that involved a ton of research on API design and code-generation tooling (with OpenAPI in particular).

I have never heard of "caniuse." Swagger? Postman? Mocking tools and services? Lots of their ilk? Sure. In fact just recently I saw this API article posted here: https://news.ycombinator.com/item?id=40161794

Re: Caniemail.com – like caniuse but for email content

#243

Post by dabacaba »

varnaud wrote: post #155
dabber wrote: post #101

Earlier quoted context omitted.

mjml looks really interesting, thanks for sharing. I wish there was a business reason for orgs to care about accessable and machine readable (I guess OCR is a thing now but still) emails. I've been using Foundation for Emails[1] for the very small number of emails that I've worked on which required more than just a list of img tags, and I really appreciate it for existing because HTML emails have been stuck in ie6 we…

I assume most email client support email with both html and txt content. If they don't support html or configured not to display it, the txt version is displayed. We have a html and txt template for each email we send. It's not exactly double the work, but it's appreciated by some of our customers.

I have my email client configured to display messages as plain text. A large fraction of emails that I receive have a text part that is empty or has some placeholder text. Also, senders often generate the text version by taking the HTML version and just stripping all tags, which means that all links are removed. I wish I could configure my client to ignore the text part completely, and instead to convert the HTML part to plain text, which is what it is doing already if there is no text part.

Re: Caniemail.com – like caniuse but for email content

#244

Post by nimih »

idle_zealot wrote: post #147
social_quotient wrote: post #141

Earlier quoted context omitted.

Is it a “document” if it has animations and non static (video) media?

Arguably? We don't really have a standard format like that in common usage so I can't predict where people would settle on it linguistically.

An .epub file is in a lot of ways what you're asking for (it's HTML-based, it's designed to package inline media such as images and provide fallbacks if the client can't/won't make remote requests, it has limited/no scripting capabilities), and you might find it interesting to peruse its specification[1].

[1] https://www.w3.org/TR/epub-33/

Re: Caniemail.com – like caniuse but for email content

#245

Post by jasomill »

joquarky wrote: post #235
social_quotient wrote: post #141

Earlier quoted context omitted.

Is it a “document” if it has animations and non static (video) media?

PDF documents support video.

PDF documents support launching external programs.

I wouldn't want my email client to support arbitrary PDF features, either.

Re: Caniemail.com – like caniuse but for email content

#246

Post by ktosobcy »

rakoo wrote: post #167
ktosobcy wrote: post #142

Earlier quoted context omitted.

1. all links are click-able at this point; what's more plain-text would force to provide just a link without all the tracking garbage 2. you can have paragraphs and headings... it's just a matter of structure - using html you can write a wall of text just fine 3. not sure if needed, besides you can attach images to plain text (though not inlining) or click-able links to external sources (at exact place) 4. still - ea…

> what's more plain-text would force to provide just a link without all the tracking garbage I'm glad that you never ever received any link to some derivation of st.es.rui.tracking/bzzz/pfrrrrt?campaign=hn that hide the real link, but in the real world, that's how tracking is done. Plain text doesn't prevent anything. > not sure if needed, besides you can attach images to plain text (though not inlining) or click-abl…

> I'm glad that you never ever received any link to some derivation of st.es.rui.tracking/bzzz/pfrrrrt?campaign=hn that hide the real link, but in the real world, that's how tracking is done. Plain text doesn't prevent anything.

That's the thing - I do get lots of them. In the age of html+plain and abuse of tracking (because it's so easy to hide with html), plain text version is just littered with this nonsense...

For example I just got notification from allegro.pl (shopping platform) and all links have that:

`?utm_source=notification&utm_medium=cartWithPayment&utm_campaign=cef…35-c856-…-…-687c…cdd6&tr_n=buyer-cart&tr_id=f09…d40-…-…-…-05b0…7126-…__f09d2e80-…-…-…-05b0ee617126-…&tr_d=allegro.pl&tr_c=purchase-details&tr_s=LM…sCz>`

As for attachments - obvious exaggeration to dismiss actual issue: bravo…

> You want to argue that plain text is better, but your arguments are that plain tex, are better for you. Don't make the mistake to assume that your specific experience is a workable average.

Don't assume that someone using HTML actually do it conciously or is glad to receive it in that form because average user doesn't complain about it

Re: Caniemail.com – like caniuse but for email content

#247

Post by ktosobcy »

pquki4 wrote: post #205
rakoo wrote: post #167

Earlier quoted context omitted.

> what's more plain-text would force to provide just a link without all the tracking garbage I'm glad that you never ever received any link to some derivation of st.es.rui.tracking/bzzz/pfrrrrt?campaign=hn that hide the real link, but in the real world, that's how tracking is done. Plain text doesn't prevent anything. > not sure if needed, besides you can attach images to plain text (though not inlining) or click-abl…

> Don't make the mistake to assume that your specific experience is a workable average. Sadly many people on HN do exactly this, as seen in comments like "I don't use a phone and don't have a phone number, so I can't pass the anti-spam check of xx website. It is their fault" "Why do we need a UI for this? Command line is much better than this" "Why do we need to do this? I have been installing applications by compili…

Please don't conflate adopting stupid solution to a problem that goes overboard (HTML) with equally stupid being stuck in shell and building stuff and using CLI...

PS. I assume all your github readme.md are all in full-blown HTML sprinkled with tracking links? :P

Re: Caniemail.com – like caniuse but for email content

#248

Post by CRConrad »

ktosobcy wrote: post #142
lelanthran wrote: post #124

Earlier quoted context omitted.

> IMO, HTML was the worst thing that ever happened to email. Plain text content is the best content. Your first statement might be true (it's debatable). Your second is definitely false. Lets assume that HTML really was the worst thing that ever happened to email. Plain text content for email is still not the best content. People want to: 1. Click on a link in the email, not fumble with copy and paste on their phone.…

1. all links are click-able at this point; what's more plain-text would force to provide just a link without all the tracking garbage 2. you can have paragraphs and headings... it's just a matter of structure - using html you can write a wall of text just fine 3. not sure if needed, besides you can attach images to plain text (though not inlining) or click-able links to external sources (at exact place) 4. still - ea…

> 1. all links are click-able at this point; what's more plain-text would force to provide just a link without all the tracking garbage

If only. Everyone I know who isn't an IT professional -- and many who are, too! -- sends links like https://www.example.com/something/somepage/?tracker=ASfas142......

Re: Caniemail.com – like caniuse but for email content

#249

Post by CRConrad »

lelanthran wrote: post #154
ktosobcy wrote: post #142

Earlier quoted context omitted.

1. all links are click-able at this point; what's more plain-text would force to provide just a link without all the tracking garbage 2. you can have paragraphs and headings... it's just a matter of structure - using html you can write a wall of text just fine 3. not sure if needed, besides you can attach images to plain text (though not inlining) or click-able links to external sources (at exact place) 4. still - ea…

> 1. all links are click-able at this point; what's more plain-text would force to provide just a link without all the tracking garbage 2. you can have paragraphs and headings... it's just a matter of structure - using html you can write a wall of text just fine 3. not sure if needed, besides you can attach images to plain text (though not inlining) or click-able links to external sources (at exact place) 4. still -…

> More to the point, it's not plain text anymore if the user gets something that has been interpreted and then rendered by the software.

Arguably it is. It was sent as plain text and received as plain text. The fact that the recipient's software goes through and interprets that plain text and does something when it detects an URL in it doesn't change that. If the recipient were to use some other software that doesn't do that, they'd see... Plain text. Because that's what it is.

Re: Caniemail.com – like caniuse but for email content

#250

Post by CRConrad »

lelanthran wrote: post #139
ivanjermakov wrote: post #136

Earlier quoted context omitted.

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

> 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 b…

> 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...?

Post reply on HN