[deleted]
Can I Email: ‘Can I Use’ for email
191–200 of 206 posts
Re: Can I Email: ‘Can I Use’ for email
#192Earlier quoted context omitted.
Firefox Mobile renders it well for me, are you sure that the comment is not rendered as it should be (with garbage from line 1 overflowing over line 2)?
I thought the owerflow should be "well behaved" (in terms of correct layout/vertical space)? Is it correct to have "overhang" into the line below? Isn't it a case of incorrect layout?
I think it is correct, as surprising as it can be.
See this famous stack overflow answer for instance: https://stackoverflow.com/a/1732454
Re: Can I Email: ‘Can I Use’ for email
#193Earlier quoted context omitted.
Something like this? http://www.rfc-editor.org/rfc/rfc1896.txt
Markdown strikes me as a much improved version of exactly this, with the advantage that you don't have to have a supporting client to read the email, since it's simply plain text. I want to see email clients start to support Markdown, so I can just send it to everyone.
Not just email, I’d like to see browsers support Markdown natively. You can style your content. All media sites can be 100% markdown without any JS.
Re: Can I Email: ‘Can I Use’ for email
#194Why using plain text is better: - readable under any mail client and any text editor - smaller size files - safer - better accessibility and compatibility with screen readers
I don't get why plain text would be more accessible than a well-formed HTML email. A screen reader could say "this is a title", "this is a list item". In plain text, what do you get? "dash bla bla"? Though I hope screen reader are more intelligent than that, but it seems like a more complex problem than just using information given by a well-formed HTML text.
A "well-formed HTML email" is about as common as a "functioning Communist state". I'm sure they're both great, and I'll let you know when I see one.
Re: Can I Email: ‘Can I Use’ for email
#195It would be really nice to have a small and simple markup language, say some markdown standard, to be the layouting language for E-Mails. No (external) images, just links, lists, headings, basic formatting. HTML E-Mails are a security nightmare, even if "only" CSS is "allowed" and JS/iframes/external images are not loaded.
The idea of markdown is great because it it essentially a text. Even if the client would not support it, humans would be able to read it just fine. Much better and more secure than rich HTML. For example my email client won't display images by default and I am happy with that. Rich HTML should be on the web only IMO!
Re: Can I Email: ‘Can I Use’ for email
#196Earlier quoted context omitted.
Exactly. If most mail clients downloaded it automatically upon receipt instead of on view then the tracking benefits get diluted to the point of uselessness. (Actually, thinking further it would have to be done server side to avoid leaking your personal IP. For a webmail provider that’s obviously straightforward, while IMAP servers could be extended to automatically replace AMP email directives with a static HTML att…
So you want RFC 2017 basically?
No, I want AMP email to never happen. Failing that, I want the email server to un-AMP-ify incoming emails for me.
Re: Can I Email: ‘Can I Use’ for email
#197Earlier quoted context omitted.
That's a good question. The actual size of the images is not large: the problem is that I can visually see the email take a while to load properly, even for an email containing just two PNG images that are 2941 bytes and 6333 bytes respectively. If nearly every sentence were to be interrupted a few times with such delayed-loading images, the reading experience would be rather poor. (This was with the images self-cont…
Try embedding Base64 images in the email instead:
Inline base64 shouldn't have any head of line blocking or slow rendering issues, unlike embedded images-as-mime-attachments, which will normally result in one HTTP request to gmails servers per image, and without QUIC you'll get head of line blocking and limited/no HTTP pipelining making that very slow.
Inline base64 should perform fine for small images up to ~10k images I'd guess on most hardware.
If your email contains more than 10k math equations, perhaps email isn't the right tool...
Re: Can I Email: ‘Can I Use’ for email
#198Earlier quoted context omitted.
If the content isn't inline, perhaps it's better to have the mail server fetch it when the email is received, so that the sender can't track whether you are reading it. This has been discussed before with regard to external links to images. I think that always made sense, but it makes even more sense to do this when the core content is external. Then fetching it would be just another part of the SMTP/HTTP transaction…
Should it do that for all emails sent to the domain, or only for valid addresses? If they only fetch for addresses in use this will open up for an easy way for spammers to verify if an address is in use or not
Spammers can already verify if an address is _accepted_ because their message will be rejected with an error code at SMTP transmission time if it isn't.
The first stage of spam filtering, and greylisting, also reject at SMTP transmission time.
I'd do the HTTP fetch when SMTP is about to accept the message, making the HTTP round trip just another part of the transaction.
Since spam filtering is likely to look at the HTTP response, you might want to reject the SMTP transaction after seeing the HTTP response, rather than accept the SMTP transaction based on address alone.
Re: Can I Email: ‘Can I Use’ for email
#199Isn't it time for desktop clients to embed a real rendering engine? The isolation on them has reached a good level.
Every GUI desktop client I'm aware of embeds a real rendering engine. The difficult one is Outlook, because Microsoft made a conscious decision that compatibility between Outlook and Word was more important than between Outlook and web browsers. I believe the Word/Outlook HTML engine was based on IE 5.5.
They could switch depending on Doctype- it wouldn't be the first time they've done it...
Re: Can I Email: ‘Can I Use’ for email
#200Earlier quoted context omitted.
I wonder what content-types email clients support besides HTML and plaintext. Would any support mp3, mp4, markdown, org or odt? EDIT: Hmmm found this[1], and this[2]. They talk about using TROFF, TEX, Postscript, voice data, etc. I wonder if something like that ended up implemented somewhere. EDIT 2: I opened an issue[3]. [1] https://tools.ietf.org/html/rfc1049 [2] https://tools.ietf.org/html/rfc767 [3] https://githu…
E-Mails typeset in TeX sounds amazing! Right now you'd have to compile your TeX code to PDF/PS/DjVu and send that, which is far from perfect.
And imagine opening an E-mail that contains a PhD paper requires 15 minutes of compilation...