• H. S. Teoh (64/111) Aug 11 2013 The solution is to have adaptive layout that adapts itself to your
• Nick Sabalausky (50/133) Aug 11 2013 For me, it's closer to 80. With 40 the line breaks are too frequent for
• John Colvin (6/16) Aug 12 2013 I am actually going the opposite way. My go to font size when

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Sun, Aug 11, 2013 at 04:33:26PM -0700, Andrei Alexandrescu wrote:
 On 8/11/13 12:00 PM, Nick Sabalausky wrote:
On Sun, 11 Aug 2013 11:25:02 -0700
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
For a column of text to be readable it should have not much more
than 10 words per line. Going beyond that forces eyes to scan too
jerkily and causes difficulty in following line breaks. Filling an
A4 or letter paper with only one column would force either (a) an
unusually large font, (b) very large margins, or (c) too many words
per line.  Children books choose (a), which is why many do come in
that format.  LaTeX and Word choose (b) in single-column documents.



The solution is to have adaptive layout that adapts itself to your
screen.

I personally prefer single-column with no more than about 40 ems in
width or thereabouts. Anything more than that, and it becomes
uncomfortable to read.

Actually, another interesting idea is left-to-right scrolling instead of
vertical scrolling. You'd lay out the text in columns that exactly fit
the height of the screen, and have as many columns as needed to fit the
entire text. If that exceeds the screen width, scroll horizontally.


[...]
Multicolumn is best for screen reading, too. The only problem is
there's no good flowing - the columns should fit the screen. There's
work on that, see e.g.
http://alistapart.com/article/css3multicolumn.



Fixing the number of columns is bound to fail, because user screen
dimensions cannot be predicted in advance. The only *real* solution is
to use an adaptive layout algorithm that adapts itself as needed.


A. HTML has good flowing, and has had it since freaking v1. No need
for upcoming CSS tricks: As long as the author doesn't go and do
something retarded like use a fixed layout or this new "zoom out
whenever the window shrinks" lunacy, then all any user ever has to do
is adjust the window to their liking.

 
 Clearly HTML has made good progress toward reaching good formatting,
 but is not quite there yet.

Ugh. I don't consider HTML as good formatting at all. HTML+CSS still has
these shortcomings:

- No full justification by default. Existing justification schemes could
  be improved (most implementations suffer from rivers of whitespace in
  a justified paragraph -- they could learn from LaTeX here). Needs
  native hyphenation support (using JS to patch up this flaw is a
  failure IMO).

- Text width should be limited to 40em by default.

- Many layout solutions require CSS circumlocutions and hacks, because
  CSS simply isn't expressive enough for many formatting needs. This
  causes spotty browser support and fragility.

- Pixel sizes should be banned, as well as hard-coded font sizes. These
  tie you to assumptions about specific user screen dimensions, which
  are almost always wrong. In this day and age, the only real solution
  is a fully dynamically adaptive layout. Everything else is just a
  relic from paper layouts, and is a dead-end. Things like aligning
  images should be based on treating image size as an actual quantity
  you can compute sizes on; any hard-coded image sizes is bound to cause
  problems when the image is modified.

- Unable to express simple computations on sizes, requiring
  circumlocutions that make the CSS hard to read and maintain.

- Unable to express simple things like headers and footers, requiring
  hacks with floats and divs and whatnot, which, again, requires making
  assumptions about user screen size, which inevitably will go wrong.


If someone expands their browser to be two-feet wide and ends up with
too much text per line, then really they have no one to blame but
their own dumbass self.

 
 This is a frequent argument. The issue with it is that often people
 use tabbed browsing, each tab having a page with its own approach to
 readability.

The *real* problem is that webpage layout is still very much confined by
outdated paper layout concepts. The browser should be able to
automatically columnize text to fit the screen. Maybe with horizontal
scrolling instead of vertical scrolling. Layouts should be flexible
enough that the browser can resize the fonts to keep the text readable.
Seriously, this isn't 1970. There's no reason why we should still be
fiddling with this stuff manually. Layouts should be automatic, not
hardcoded or at the whims of designers fixated on paper layout concepts.


[...]
I *really* wish PDF would die. It's great for printed stuff, but its
mere existence just does far more harm than good. Designers are
already far too tempted to treat computers like a freaking sheet of
paper - PDF just clinches it for them.

 
 Clearly PDF and other fixed-format products are targeted at putting
 ink on paper, and that's going the way of the dinosaur. At the same
 time, the publishing industry is very much in turmoil for the time
 being and only future will tell what the right replacement is.

[...]

The right replacement is to have dynamic page layout that doesn't depend
on CSS hacks or other arbitrary decisions by the publisher like number
of columns, etc.. This isn't the age of paper anymore; layout should be
done automatically by the end-user's browser, not by content producers,
who should be worrying about the content, not the layout.


On Sun, Aug 11, 2013 at 04:47:09PM -0700, Walter Bright wrote:
 On 8/11/2013 4:33 PM, Andrei Alexandrescu wrote:

[...]
 Currently ereaders are great for reading novels and such with little
 typography needs. But they're terrible for textbooks and reference
 material, mainly because the screen is both low res and is way too
 small.
 
 It's like programming with an 80*24 display (I can't believe I was
 able to use them!).

[...]

I still program with 80*24 displays. Well, more like 80*40, but I find
that it's actually far more readable than the common obsession with
squint-inducing microscopic fonts trying to cram as much on the screen
as possible. Having too many characters per line quickly gets very hard
to read.


T

-- 
Time flies like an arrow. Fruit flies like a banana.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Sun, 11 Aug 2013 20:01:27 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:
 
 I personally prefer single-column with no more than about 40 ems in
 width or thereabouts. Anything more than that, and it becomes
 uncomfortable to read.
 

For me, it's closer to 80. With 40 the line breaks are too frequent for
my eyes. And it just "feels" cramped.


 
 - No full justification by default. Existing justification schemes
 could be improved (most implementations suffer from rivers of
 whitespace in a justified paragraph -- they could learn from LaTeX
 here). Needs native hyphenation support (using JS to patch up this
 flaw is a failure IMO).
 

To be honest, I'm not a big fan of justified text. Obviously I can live
with it, but even without the occasional "rivers of whitespace" issue,
I find the lack of jagged edges gives my eyes too few reference points,
so I end up losing my place more easily. The value of justified text's
smooth edges, to me, seems somewhat "Adrian Monk" (wikipedia, if you
don't know).


 
 - Pixel sizes should be banned, as well as hard-coded font sizes.
 These tie you to assumptions about specific user screen dimensions,
 which are almost always wrong. In this day and age, the only real
 solution is a fully dynamically adaptive layout. Everything else is
 just a relic from paper layouts, and is a dead-end.

Yea. Admittedly, I do occasionally use pixels for a little bit of
spacing here and there (never for more than 8px), but I can happily
give them up - especially with so much now using those ultra-high pixel
density screens. Pixels just don't make much sense now unless you're
already dealing on a raster level anyway, like a photo or something.


 Things like
 aligning images should be based on treating image size as an actual
 quantity you can compute sizes on; any hard-coded image sizes is
 bound to cause problems when the image is modified.
 
 - Unable to express simple computations on sizes, requiring
   circumlocutions that make the CSS hard to read and maintain.

Yes! That's one of my big issues with CSS, the inability to do anything
computationally. And yea, dealing with images tends to make that become
more of an issue.

Ultimately, the root problem here regarding the lack of computability,
is that HTML/CSS is not, and never has been, a UI layout format (No
matter how much people insist on treating it as
such...*cough*mozilla*cough*.) It's a *document* format. Always has
been. Everything else is a kludge, and is doomed to be so from the
start.


 
If someone expands their browser to be two-feet wide and ends up
with too much text per line, then really they have no one to blame
but their own dumbass self.

 
 This is a frequent argument. The issue with it is that often people
 use tabbed browsing, each tab having a page with its own approach to
 readability.

 
 The *real* problem is that webpage layout is still very much confined
 by outdated paper layout concepts. The browser should be able to
 automatically columnize text to fit the screen. Maybe with horizontal
 scrolling instead of vertical scrolling. Layouts should be flexible
 enough that the browser can resize the fonts to keep the text
 readable. Seriously, this isn't 1970. There's no reason why we should
 still be fiddling with this stuff manually. Layouts should be
 automatic, not hardcoded or at the whims of designers fixated on
 paper layout concepts.
 

Exactly. In fact, we *already* had all this. It was called HTML 1. But
then some jackass designers  came in from the print world and demanded
webpages match their photoshop mockups to the pixel, thus HTML mutated
into the world's worst UI layout system. (Of course I skipped a few
steps there, but you get the picture.)

If we weren't trying to force app UIs and manual page layouts into web
pages, we could have *already* had nice document layout systems
tailored to the individual user (with tabbed browsing *not* being an
obstacle to basic window resizing, and with multiple device form
factors *never* being an issue for any content creator), instead of
this current endless circle where W3C occasionally hands out some new
half-baked CSS gimmick that a few of the more overzealous designers can
optionally employ in order to force a one-size-fits-all approach to
"readability" onto everyone who visits that one particular site, thus
leading to inevitable problems and ultimately the W3C's next round of
half-baked hacks to the CSS spec.


 
 [...]
I *really* wish PDF would die. It's great for printed stuff, but
its mere existence just does far more harm than good. Designers are
already far too tempted to treat computers like a freaking sheet of
paper - PDF just clinches it for them.

 
 Clearly PDF and other fixed-format products are targeted at putting
 ink on paper, and that's going the way of the dinosaur. At the same
 time, the publishing industry is very much in turmoil for the time
 being and only future will tell what the right replacement is.

 [...]
 
 The right replacement is to have dynamic page layout that doesn't
 depend on CSS hacks or other arbitrary decisions by the publisher
 like number of columns, etc.. This isn't the age of paper anymore;
 layout should be done automatically by the end-user's browser, not by
 content producers, who should be worrying about the content, not the
 layout.
 

Exactly. In other words, the right solution is more or less equivalent
to HTML 1 or 2.

They already had it pretty much right back in the 90's. But then people
wanted their "dancing pigs" so to speak, and we ended up with this
unholy mutant we have know: HTML 5. World's worst UI format, and no
longer a good document format either.

...And yet 9 times out of 10 it *still* ends up far more readable
on-screen than an 8.5" x 11" two-column PDF. Go figure.


 
 On Sun, Aug 11, 2013 at 04:47:09PM -0700, Walter Bright wrote:
 On 8/11/2013 4:33 PM, Andrei Alexandrescu wrote:

 [...]
 Currently ereaders are great for reading novels and such with little
 typography needs. But they're terrible for textbooks and reference
 material, mainly because the screen is both low res and is way too
 small.
 
 It's like programming with an 80*24 display (I can't believe I was
 able to use them!).

 [...]
 
 I still program with 80*24 displays. Well, more like 80*40, but I find
 that it's actually far more readable than the common obsession with
 squint-inducing microscopic fonts trying to cram as much on the screen
 as possible. Having too many characters per line quickly gets very
 hard to read.
 

Heck, I started out on the 40-character-width AppleSoft BASIC. Although
I'm sure other people can best me on that (altair, punch cards, etc). 

"John Colvin" <john.loughran.colvin gmail.com> writes:

On Monday, 12 August 2013 at 03:02:59 UTC, H. S. Teoh wrote:
 I still program with 80*24 displays. Well, more like 80*40, but 
 I find
 that it's actually far more readable than the common obsession 
 with
 squint-inducing microscopic fonts trying to cram as much on the 
 screen
 as possible. Having too many characters per line quickly gets 
 very hard
 to read.


 T

I am actually going the opposite way. My go to font size when 
coding is now 8pt, I can't stand working with anything much 
larger.
I wouldn't use anything that large for publishing, but it's my 
preference for reading code.