Yes, the ideal ("most legible") width for a column of text is ~60 characters, no question. But that's only once you've chosen the most legible font size.
You're supposed to adjust your column width to fit an appropriate number of characters, not adjust the font size to your column width! Adjusting the font size is completely backwards, and worst of all, it's breaking my browser zoom, so it's terrible for usability.
This is a cool demo, but absolutely not something to be used in production. (Sorry to be so negative about it, but the whole project seems based on a misunderstanding of an important design principle.)
Yes, the ideal ("most legible") width for a column of text is ~60 characters, no question.
We can reasonably question what makes a good line length as well.
You have to define what you’re trying to achieve first. For example, a line length that is subjectively pleasing to readers in a certain context might not be the same as a line length that optimizes measured reading speed or retention.
Once you’ve done that, differences start to emerge. During research studies, readers have often preferred shorter line lengths (typically around 40-50 characters) over longer ones (say 60+). However, in terms of reading speed, lines as long as 100 or so characters have sometimes resulted in better measured performance. Please note that I’m oversimplifying horribly here, both ignoring established confounding factors like font and line spacing, and ignoring context such as screen vs. print or paged vs. scrolling presentation.
So, while the old rules of thumb like “two alphabets” seem to be reasonable starting points, we shouldn’t assume that they are optimal in all cases.
On another note, you should probably have a "minimum" font size option. Cause right now if I shrink my window to just before it switches media queries removing the box/scroll thingy. And move the scroll thingy to the far right, the font is like size 1px.
While that may not matter as that is a rare case, if I am using a javascript library to control my font size (which is ridiculous if you ask me, but let's ignore that) I don't ever want it to go below 10px's. And there are tons of different Android screen sizes, so this is a possibility.
As a web designer, I despair of users upping the font size and screwing up the words-per-line. Which is why I like Safari's iOS-like pinch-zoom feature. I do wish all browsers would move in that direction and in the end disallow users to arbitrarily up font sizes.
That said, crazygringo's point is valid insofar as people do up their font sizes as a matter of course.
I bet that this can be useful in some cases, don't assume that it has to be used to present paragraphs of flowing text, as in the demo. For example MS Excel has this feature for shrinking the font size when you shrink a column, and some users finds it invaluable. This library could help implement this feature in a web based spreadsheet.
I commented on this elsewhere, but this didn't break my zoom at all — although I did have to bump it up to around 200% to start seeing increases. You could argue this is inconvenient, but not quite broken.
We've moved beyond simple negative attacks here at HN. Maybe a list of considerations or caveats would have been more approrpriate. The idea is novel, and this particular solution probably has many uses.
Yes, the ideal ("most legible") width for a column of text is ~60 characters, no question. But that's only once you've chosen the most legible font size.
You're supposed to adjust your column width to fit an appropriate number of characters, not adjust the font size to your column width! Adjusting the font size is completely backwards, and worst of all, it's breaking my browser zoom, so it's terrible for usability.
This is a cool demo, but absolutely not something to be used in production. (Sorry to be so negative about it, but the whole project seems based on a misunderstanding of an important design principle.)