I don't like articles where I need to bring up the browser dev tools just so I can read it.
I don't like articles where I need to bring up the browser dev tools just so I can read it.
Resizing the window takes just over two seconds to redraw, rather than being instantaneous. And when that affects the width of the text, it doesn't recolour them, so you get a bad mess. And using it on an article this long causes Firefox to have on its account explicit allocations of 214 MB, rather than the 20MB that I would consider to be slightly excessive but permissible.
Oh, I hate that thing.
Better solutions include:
Using a more optimal column width. 50-60 characters per line is a commonly suggested range for most media.
Using a more optimal leading (line-height). "Set solid" type (ex. 12px/12px) is almost always a bad idea, particularly so in a long block of text. Depending on the type, media, etc, ratios in the range of 1.2-1.8 are a good starting point for improving readability.
http://www.gwern.net/AB%20testing#max-width-redux
> Using a more optimal leading (line-height).
[0]: http://www.gwern.net/AB%20testing [1]: http://www.gwern.net/AB%20testing#beeline-reader
(And the people responsible for the BeeLine Reader website know this! Even maximized, their body copy is split into two columns each about fifty characters wide.)
I didn't find narrower versions to perform well: http://www.gwern.net/AB%20testing#max-width-redux
Ignore my 487 unread emails. I need to clean that out...