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.)

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.

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.

That said, crazygringo's point is valid insofar as people do up their font sizes as a matter of course.

Seriously, where do web "designers" get off these days? The web is not paper.

Most users probably don't want to spend their life panning around a page to see what's going on.

Page is absolutely beautiful though.

There was once I worked on a web app, which was supposed to be viewed on viewports as small as a laptop to viewports as big as a four 57" TVs strung together. Back then, I had to come up with something similar to this to make the content of the TVs visible from a distance. This library would have come really handy back then.

   p { line-height: 1.45; }

Also, the whole notion (and seemingly a sub-trend of responsive design) of page content (fonts/images) scaling to try and maintain structure when the page is resized is naive to the point of being ridiculous.

This is the wrong solutions.

There is a reason why 16pt is the standard font-size. And its no problem to design a responsive website with columns that use 'between 45 and 75 characters per line'.

For instance, the comment threads on HN are at 12px (9pt), and are entirely legible for me.

oh yeah, you're right 9pt is very readable for me too.

I like the idea, but I don't think fully automatic font scaling is the way to go. Mapping resolution to font size (which is essentially what the Javascript magic does) doesn't work because resolution doesn't mean much anymore. An HD tablet and a 27" monitor have the same resolution but demand completely different text sizes because you sit so much farther away from a desktop monitor.

So for the time being I think the best way to go is to create a mostly fluid layout and to write custom CSS for manual adjustments to make sure it looks good on smartphones, tablets, laptops and desktop monitors.

The only major browser that apparently doesn't support vw is Android stock browser (Chrome on Android does support it). Even my PS Vita browser supports the units.

However, not all CSS styles support viewport units. border-width, a few others. But you can define the doc's font-size in vw (font-size: 1vw;) and then use rem units everywhere to get around those few compatibility issues. (It works.)

The demo impressively shows, that this is not the case for narrow viewports. However, the idea is great.

I don't know where this 'my-font-is-bigger-than-your-font"-trend started, but I can't wait for it to be over.

Couldn't you do it with viewport units?

Not every library / tool has to be universally applicable to be useful.

You might want to revisit how the font-size (and line-height) do not always remain in perfect sync to the element-width. What we've here is the ratio of font-size over width-of-the-element. Since font-size doesn't depict width of the font accurately, a percentage change in it doesn't reflect proportionally to revised width of the element(.demo-type). Hope this helps.

We call this resolution stationary rendering internally and use it in our product: https://bubbleideas.com/letters/the-tiger-by-sir-william-bla...