4 ms·

It's not Colin's fault that you're using a browser that can't render an html rendition of an email which has been widely in use since before iOS existed. This

It's not Colin's fault that you're using a browser that can't render an html rendition of an email which has been widely in use since before iOS existed. This is entirely Safari's fault for not having good compatibility with a common existing webpage format. Anyway, if you're the intended audience (someone using tarsnap), you also received a copy to your email address, where you can read the text with your email reader of choice.

deleted 3y ago
[deleted]
Kwpolska 3y ago
How should a browser differentiate between a <pre> of hard-wrapped prose (that it could reflow in reader mode) and a <pre> of code?
- TheDong 3y ago
  In an email you can't of course since an email could contain one, the other, or a mix. And, in fact, most mailing list emails I read these days do contain code and code reviews. However, if the user clicked the "reader mode" button, that's a good sign the user thinks this is reflowable text. Firefox's reader mode figures this out. Safari's doesn't.
  - Kwpolska 3y ago
    Or you might use Reader Mode on a programming blog, which has both prose and code, and you wouldn’t want to change the code in that case.
switch007 3y ago
A <pre> is the correct kind of HTML use for the body of plain text email ? It looks like paragraphs of text to me. <p> is far more appropriate That isn’t apple’s problem, nor mine.
- TheDong 3y ago
  pre is the only correct element to use since in many emails, the exact formatting and linebreaks and such are important. For example, a code review on a mailing list can only make sense with the linebreaks and spacing preserved. However, as you knew to try, there is "reader mode", which is meant to heuristically ignore the exact html in order to display textual content. Firefox's reader mode has no trouble figuring out that this is a block of text that can be reflowed. Safari's heuristics clearly fall short on one of the more common kinds of textual blurbs you might want to reader-view-ize. Seems like a safari problem to me.
  - KronisLV 3y ago
    > Firefox's reader mode has no trouble figuring out that this is a block of text that can be reflowed. It was absolutely unreadable on mobile Firefox (Android), initially didn't even think to use the reader mode, which indeed did help make it readable! I think this is the first time I've ever actually needed that functionality, never quite got it beforehand. Thanks for the suggestion!
  - switch007 3y ago
    Ok you changed my view
- jrockway 3y ago
  <pre> is the correct HTML. People writing plain-text email expect to be able to do things like add ASCII diagrams: ------- ------- | foo | ---> | bar | ------- ------- It's an older technology but it checks out.
- bananapub 3y ago
  it's a plain text email, which is exactly the sort of thing <pre> is for - pre-formatted text
Aeolun 3y ago
The HTML rendition in this case did it’s best to be hard to read. It’s not impossible, and likely just a fault of whatever list thing is used, but it could be better, and it’s nice if people let you know as such right?
- prmoustache 3y ago
  How can simple black on white text with a lisible font be hard to read?
  - Aeolun 3y ago
    It doesn’t adjust to my screen size. So in portrait mode I have sentences with 80 characters per line that are 5 points wide. That’s barely possible to read on a high dpi screen, but fairly uncomfortable.
    - prmoustache 3y ago
      I understand some websites are doing lots of funky stuff, but at this point the issue is on your particular client if it cannot zoom bare text correctly and smoothly. Any decent client should be able to allow you to zoom it so that you can maximize those 80 character column to the width of your phone screen in protrait mode regardless of font size and dpi.
      - Aachen 3y ago
        Try it if you don't have a perfect 100% vision (20/20 this is called in USA I think?) and have a phone that fits in a normal pocket Optimal reading width for speed/comprehension is also fewer than 80 characters afaik. I think different sources I read years ago were undecided whether it's closer to 60- or 70-character lines. Either way, rescaling when there is no ASCII art or position-dependent characters seems rather basic and <pre> disallows that
        prmoustache 3y ago

deleted 3y ago

[deleted]

Kwpolska 3y ago

How should a browser differentiate between a <pre> of hard-wrapped prose (that it could reflow in reader mode) and a <pre> of code?

TheDong 3y ago
In an email you can't of course since an email could contain one, the other, or a mix. And, in fact, most mailing list emails I read these days do contain code and code reviews. However, if the user clicked the "reader mode" button, that's a good sign the user thinks this is reflowable text. Firefox's reader mode figures this out. Safari's doesn't.
- Kwpolska 3y ago
  Or you might use Reader Mode on a programming blog, which has both prose and code, and you wouldn’t want to change the code in that case.

switch007 3y ago

A <pre> is the correct kind of HTML use for the body of plain text email ? It looks like paragraphs of text to me. <p> is far more appropriate That isn’t apple’s problem, nor mine.

TheDong 3y ago
pre is the only correct element to use since in many emails, the exact formatting and linebreaks and such are important. For example, a code review on a mailing list can only make sense with the linebreaks and spacing preserved. However, as you knew to try, there is "reader mode", which is meant to heuristically ignore the exact html in order to display textual content. Firefox's reader mode has no trouble figuring out that this is a block of text that can be reflowed. Safari's heuristics clearly fall short on one of the more common kinds of textual blurbs you might want to reader-view-ize. Seems like a safari problem to me.
- KronisLV 3y ago
  > Firefox's reader mode has no trouble figuring out that this is a block of text that can be reflowed. It was absolutely unreadable on mobile Firefox (Android), initially didn't even think to use the reader mode, which indeed did help make it readable! I think this is the first time I've ever actually needed that functionality, never quite got it beforehand. Thanks for the suggestion!
- switch007 3y ago
  Ok you changed my view
jrockway 3y ago
<pre> is the correct HTML. People writing plain-text email expect to be able to do things like add ASCII diagrams: ------- ------- | foo | ---> | bar | ------- ------- It's an older technology but it checks out.
bananapub 3y ago
it's a plain text email, which is exactly the sort of thing <pre> is for - pre-formatted text

Aeolun 3y ago

The HTML rendition in this case did it’s best to be hard to read. It’s not impossible, and likely just a fault of whatever list thing is used, but it could be better, and it’s nice if people let you know as such right?

prmoustache 3y ago
How can simple black on white text with a lisible font be hard to read?
- Aeolun 3y ago
  It doesn’t adjust to my screen size. So in portrait mode I have sentences with 80 characters per line that are 5 points wide. That’s barely possible to read on a high dpi screen, but fairly uncomfortable.
  - prmoustache 3y ago
    I understand some websites are doing lots of funky stuff, but at this point the issue is on your particular client if it cannot zoom bare text correctly and smoothly. Any decent client should be able to allow you to zoom it so that you can maximize those 80 character column to the width of your phone screen in protrait mode regardless of font size and dpi.
    - Aachen 3y ago
      Try it if you don't have a perfect 100% vision (20/20 this is called in USA I think?) and have a phone that fits in a normal pocket Optimal reading width for speed/comprehension is also fewer than 80 characters afaik. I think different sources I read years ago were undecided whether it's closer to 60- or 70-character lines. Either way, rescaling when there is no ASCII art or position-dependent characters seems rather basic and <pre> disallows that
      - prmoustache 3y ago