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.
I don't know why all the negative comments here. Just because this solution doesn't fit any of your use cases, it doesn't mean it's a bad solution.
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.
This is entirely the wrong solution to a problem that doesn't even exist. In actual fact the problem is fonts are too small on my mobile devices so I'm constantly zooming in... why would I want my on screen text to start off a couple of pixels high?
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.
So on small screens this will make the font even smaller.
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'.
Not for me on a 1080p 27-inch monitor from a reasonable distance. I have to browse Hacker News at 125%, and Reddit at 110% - although almost all other websites work fine.
I think this is pretty cool (and I like the slider-demo!), but it's clearly developed for laptops and mobile devices. On a bigger monitor the website is essentially unreadable. A 29px font for the body copy is a bit outrageous.
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.
They're pretty well-supported now, I did my blog's entire CSS in vw units.
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 script can be extremely useful and the concerns raised regarding readability can be overcome using the min and max width. If you adjust line height in conjunction with font-size and font selection, text can be readable from 12pt and up, even at 10pt.
Why this kind of functionality hasn't been part of the HTML standard from day one boggles the mind. There are many good use cases for this. You don't have to use it for everything, btw, even just having it adjust a header could be useful.
the site also impressively shows that this leads to horrendously large font-sizes on a normal (1920x1200) monitor. it looks like medium on steroids, and makes the site scream at me like there's no tomorrow.
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.
Another solution in search of a problem that doesn't exist. If your viewer has a small screen REDUCE YOUR CONTENT. You probably have lots of waffle you don't need anyway. Conversely if they have more screen real estate than brain cells and expand their window to 2000px+ they are stupid. Don't encourage them.
Love it. This is great for some very specific use cases (thinking about wall displays / large dashboards). It is definitely NOT for accessibility or for the bulk of text on most web pages.
Not every library / tool has to be universally applicable to be useful.
This would be a nice user script / bookmarklet, but I don't think websites (except for Readability-type apps) will ever need this. Proper responsive design and usability testing are the correct solution, not this... "hack". But since we're at HACKernews after all, cool effort and props for a very comfortable + practical landing page! Kudos!
This is nice, but you'll see some alphabets or words would get wrapped into new lines when the element(.demo-type) is resized. It's a minor but subtle effect.
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.
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.)