It rather supports the site's core point, because that point is about plain text files, not HTML and CSS. Plain text is as readable as it is possible to be.
Besides, this is exactly the kind of site HN constantly laments the loss of - unique, quirky, basic and rough around the edges.
> Plain text is as readable as it is possible to be.
Which is nonsense, of course, just like this site illustrates. Trivial formatting and layout changes make it more readable.
> Besides, this is exactly the kind of site HN constantly laments
And this is exactly the beside-the-point response you sometimes encounter on HN. I'm not a representative of the collective HN, so why does it matter that some other people did some lamenting some time ago?
They do, and it's even misapplied in this example - there are weird hard line breaks (an ASCII character) in the wrong places, breaking the supposed "accessibility" of the format.
But also, you continue to miss the point - this lacking/bad layout/formatting is precisely the reason not to use plain text
> there are weird hard line breaks (an ASCII character) in the wrong places
They aren't in the wrong place, if you view the site on desktop, or mobile browser in desktop-mode (for me at least), or the source, the line-breaks form proper paragraphs. Looks like the host actually delivers HTML/CSS with wrapping rules instead of plain text though, which messes it up for screens narrower than a full line in the file.
But either way, the file remains perfectly readable even with the added line breaks, not like any text is missing or moved.
I'm amused by all the plaintext defenders not being able to parse this simplest of the file formats!
> if you view the site on desktop ... , or mobile browser in desktop-mode (for me at least), or the source, the line-breaks form proper paragraphs
Nope. The first paragraph consists of 3 lines (#9,10,11), so has 2 extra linebreaks (both in desktop and source form). The next one is lines #13-21, so has 8 extra linebreaks. Because of that it doesn't reflow properly, so looks bad at most of the screen widths
> not like any text is missing or moved.
It is moved due to linebreaks, here is a simple example: the notation of the numbers is force-moved to the next line instead of being adjacent to the numbers, this hurts your "perfect" readability
> re characters 32 to 126
> (decimal)
There is nothing perfect about readability of the poorly formatted/laid out text! And doing everything "plainly" simply robs you of the ability to reach the expressiveness available even to the cave man
>But also, you continue to miss the point - this lacking/bad layout/formatting is precisely the reason not to use plain text
I don't miss the point, I rather disagree with your opinion.
Formatting and layout are properties of the client, and you can display plaintext in any color or font you wish.
But the default - plain white background and plain black text with a simple serif or sans-serif font simulating a paper document - is perfectly readable.
So why can't you address it instead of coming up with an alternative argument again?
> Formatting and layout are properties of the client
No, I've given you a specific example - forced newlinew - of layout that is not a property of the client. ======================= is another example, this time it's formatting, also not a client property
Besides, this is exactly the kind of site HN constantly laments the loss of - unique, quirky, basic and rough around the edges.