> Nice, I like text files. Paragraph width is a little too wide for me, however.
This is why we need markup languages like HTML. Inevitably people will want different widths paragraphs due to different devices, preferences, etc. Just because some people use HTML badly doesn't mean we need to go back to text.
Ideal paragraph width is not a function of device display size. A line of text should contain about 12 words, give or take. Long enough to not feel choppy but short enough to not feel like a "wall of text."
Deviate too much from this and readability suffers.
Edit: adequate whitespace in the margins is important too.
But it wouldn't handle indentation properly, unless you define a standard formatting convention similar to Markdown. For example, you need to handle bullet points. But what if a plain, non-indented text just happens to contain a star at the start of a line? This means headaches for text writers to avoid these edge cases, and wrong indentation when viewing legacy texts.
Also, all viewers would have to support it, which somewhat defeats the purpose of using plain text.
I'm not talking tab characters, I'm talking indentation of whole paragraphs with plain spaces, as seen in the article. Most existing viewers just wrap long lines so that the wrapped content is unindented: this makes any indentation hard to notice and mostly useless. For your proposition to be viable, viewing software has to detect indentation and keep that indentation in wrapped lines.
> Asterisks are fine.
Ok, but usually you want to indent the wrapped contents by 2 columns otherwise asterisks become hard to notice. This is only possible with special magic in the viewer.
--- BEGIN MESSAGE ---
--- BEGIN BLOCK QUOTE ---
--- BEGIN BLOCK QUOTE ---
I'm not talking tab characters, I'm talking indentation of whole paragraphs
with plain spaces, as seen in the article.
--- END BLOCK QUOTE ---
Ah, okay. You're right, indenting an entire paragraph is hard.
--- BEGIN BLOCK QUOTE ---
This is the kind of thing they'd do on Usenet.
--- END BLOCK QUOTE ---
--- END BLOCK QUOTE ---
All you get is a very verbose markup language :-)
--- END MESSAGE ---
This is the best solution, because you never know how large the text will be when rendered by the user's software. For example, this is how it rendered on my iPad:
You Europeans have things too easy with your metric paper sizes and sales tax included in displayed prices and standardized road signage and drinkable beer and functional healthcare systems. We'll stick with PDFs, and fluid ounces, and trying to calculate 18% of pretax dinner tabs thanks. Excuse me while I go fight with my health insurance company over my last doctor bill.
I'd say it's more than fine. I just spent three weeks in Europe and I was underwhelmed by the beer everywhere except Munich, Berlin, and Copenhagen (Mikeller was great). Foreigners seem to think of American beer as PBR, Bud Light, Miller, etc... and they have a good reason to--it's what most Americans drink.
But the strong microbrew renaissance going on right now is producing some of my favorite beers. Beers with the same depth and complexity as the finest of wines--he said, opinionatedly.
Now, I've learned that this experimental attitude towards beer is highly American. I don't think I've seen anywhere else in the world, except maybe Belgium, that is quite as crazy and experimental with what they put in their beers. After all, who in their right minds would like sour beers?
If you think the beer situation in the US is poor try out some Russian River, Boulevard, or Elysian brews and come back to me.
This is why we need markup languages like HTML. Inevitably people will want different widths paragraphs due to different devices, preferences, etc. Just because some people use HTML badly doesn't mean we need to go back to text.