Hacker News new | past | comments | ask | show | jobs | submit login

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.




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.


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.


> 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!


Ok you changed my view


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


it's a plain text email, which is exactly the sort of thing &lt;pre&gt; is for - pre-formatted text


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?


How can simple black on white text with a lisible font be hard to read?


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.


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.


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


I am using prescription glasses. That is what they are for. If you are using yours and still can't read small text, you need a visit to your optiometrist and get new ones.


What about us poor slobs whose vision is less than perfect where the 80-character line is too small even when it takes up the entire width of the display? The way zooming is implemented in the mobile browsers, we must horizontally scroll back and forth for every line we read.


I am using prescription glasses. That is what they are for. Maybe you should use yours?


I don't think my glasses can correct my vision well enough to be able to read 80-char-wide text on a smartphone in portrait mode. I can't say for sure because I don't own a smartphone--partly because I worry about being able to read web pages on it without regularly resorting to the aforementioned tedious horizontal scrolling.

I always wear my glassses when I'm using my iPad, which is in landscape mode almost all the time (the exceptions being the rare apps like Uber's that won't do landscape mode).


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


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.


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.




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

Search: