311–320 of 345 posts
Earlier quoted context omitted.
iiiiiiiiiiiiiiiiiii |||||||H|A|P|P|Y||||||| __|_____________________|__ |\/\/\/\/\/\/\/\/\\/\/\/\/\/| |||||||B|I|R|T|H|D|A|Y||||||| |,,,,,,,,,,,,,,,,,,,,,,,,,,,| @@@@@@@@@@@@@@@@@@@@@@@@@@@@@
That would be a wide cake for older people :P
Earlier quoted context omitted.
Then you are better off using some format that can stand alone as a file such as PDF. If it is a reference document that is intended to be edited on an ongoing basis it is better to use something like a wiki. Having to root around in your email to find a reference document is pretty inefficient and annoying.
We send syntax highlighted code all the time via email at my job. I hope you're not suggesting we should use PDF instead? And no, creating snippets on a wiki is also an extra unnecessary step. Email is just easier and faster.
send the plaintext code snippet and they'll decide.
Earlier quoted context omitted.
> An internet forum (presumably we're referring to a public forum here) is a very different communication medium than email Not really. Take a look at any email discussion like the Linux kernel mailing list or the git mailing list. Same thing with newsgroups (usenet).
> Same thing with newsgroups (usenet). good lord, how old are you?
Earlier quoted context omitted.
I see useful text formatting every day in the emails I send and receive. A reasonable person would accept that other people’s use cases and preferences are valid instead of writing haughty diatribes about what the platonic ideal of email should look like.
I accept that other people's use cases and preferences differ. But given the carnage that HTML e-mail being the normal has caused in phishing and other privacy invading manners, I question whether the benefits of those use cases and preferences out-weight the detriments of the practice. Just ask John Podesta: > SecureWorks concluded Fancy Bear had sent Podesta an email on March 19, 2016, that had the appearance of a…
>
>
> https://c.na39.content.force.com/servlet/servlet.EmailAttach... [...] ">
>
> Attachment not opening? Click this link: https://c.na39.content.force.com/servlet/servlet.EmailAttach... [...] ">ColorAnalysisWithOMA300.pdf
>
From a post made today:
Earlier quoted context omitted.
> Content should be separated from presentation. Not necessarily. There are times where text should not be wrapped (code snippets, error messages, or log output), but if text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown. This requires that the client supports that type of markup which isn't always the case. There is an RFC[1] t…
> If text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown Precisely. HTML and markdown separate content from presentation, so content that should never be wrapped - like ```code``` or code is handled properly.
Earlier quoted context omitted.
Are you actually a user of accessibility? To me, it doesn't feel like you are. If I am right, please refrain from patronizing people who actually do. In my book, you have no idea how horrible the situation has become over the last 5 to 10 years. Accessibility used to be a thing, yes. These days, it is mostly a happy accident.
I've never talked to anyone who actually used accessibility tools. I'm aware of the W3C standards. Are there any other resources that developers can use to produce stuff that works well with real-world accessibility software?
Earlier quoted context omitted.
I'm very sad about manual line wrapping too (since I love plain text otherwise), but unfortunately it's in the MIME standard. > Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. Of course with HTML, your source code can adhere to this standard while still having arbitrarily long lines of text... https://mailformat.dan.info/body/linelength.html
It’s an outdated standard and a terrible idea nowadays, since it makes emails unreadable on mobile devices. I’d really love to use plain-text emails — hell, I use plain text for everything — but they’re sadly not a good idea today, unless you want your emails looking like crap on every mobile device. The suggestion to use `format=flowed` doesn’t help, as the standard is ill-supported: https://fastmail.blog/2016/12/17…
1. Lack of support
2. Lack of people sending/reading plain text email
3. HTML bloat is no longer a real concern
Then they make some implementation difficulty arguments
1. Implement an editor that supports only semantic blockquoting
2. Fix "embarrassing line wrap" due to clients that lack support
For the first 3 arguments, I would say that lack of support from other clients doesn't mean that a client shouldn't support it. I regularly posted to usenet with Thunderbird (which supports format=flowed) and had people respond to my posts with clients that didn't support that feature.
To them (and when viewing the message source), the messages still appeared to be hard-wrapped. When viewing the messages in Thunderbird, the parts I typed were softwrapped. "Embarrassing line wrap" simply did not happen (no matter many times a given piece of text was quoted). "Embarrassing line wrap" was only an issue because certain clients would further re-wrapped quoted text without taking the quote markers into account instead of just leaving it alone or properly re-wrapping it.
Text editors like emacs and vim have features that will easily re-wrap quoted email text. Thunderbird has a feature where you can highlight quoted text and press ctrl-r to rewrap it. So I don't really see how it's difficult to eliminate the "embarrassing line wrap" issue when there are open source programs out there that have the capability (for several decades now) to fix it.
And I think they're missing the point by saying that HTML bloat is no longer an issue. It's not the amount of text that's transferred; it's how readable it is in a client that doesn't support rendering that text. IOW, reading raw HTML is not that easy.
As for implementing an editor that only supports semantic block quoting, I think they're missing the point again. It should be the person who's composing the email who decides whether a particular section of text should be hard-wrapped (meaning no trailing whitespace at the end of each line). You could have a feature where you highlight the text you want hardwrapped and then use a key combination or context menu to apply that change. The rest of the text is assumed to be soft-wrapped and will have trailing whitespace at the end of each line unless that line followed by a blank line.
Earlier quoted context omitted.
Not sure if that's what you're looking for, but you could use notmuch[0]. Haven't used it a lot, but I think it can import an mbox? Maybe you can merge multiple mboxes together? [0]: https://notmuchmail.org
I looked into that a few times, just haven't had the patience to get through the setup process. Maybe I'll get it done this time. There goes my afternoon :)
Earlier quoted context omitted.
Go and visit a forum where embedded images are allowed and tell me that there is any sort of "optimum" discussion over there. In the end what happens is people use text overlays in the IMAGES in order to reply to each other. Since you edited your response to mention the birthday card: Yea - on the one hand you can leave a boring "Happy Birthday" message with lots of glitter to make it memorable. Or you can make the m…
> In the end what happens is people use text overlays in the IMAGES in order to reply to each other. That doesn't sound optimum use of image at all. > Or you can make the message memorable. And use image that make it even more memorable at the same time. Text and images are tools, both can be misused, but that doesn't means that they are bad. Remember SMS text? Works for sure, clearly not optimal, yet text is pretty…
That way the big screenshots don't destroy the flow of text like in http://example.jpg [+] (open inline) and instead information is condensed and digested in the most optimum way possible.
Earlier quoted context omitted.
> For me as a reader having to read both an E-Mail and the attached PDF is also annoying, and many people will simply skip reading the PDF. See also embedding (e.g.) a JPEG in a Word document and then attaching that Word document to an e-mail.
I've seen so many Word or PPT documents with a single hyperlink in them, uploaded to SharePoint with filenames like "process_manual_2013_v3.2.doc"... Ugh.
* https://old.reddit.com/r/sysadmin/comments/ch83sz/why_the_he...
