FlowType: font-size and line-height based on element width | Hacker News Reader

FlowType: font-size and line-height based on element width

simplefocus.com

148 pointsaadlani52 comments

PLEASE do not use this.

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

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.

Different experience here. Definitely broke my zoom.

Page is absolutely beautiful though.

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.

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.

Yes, those silly people with bad vision.

He did not say that he wishes for people not to be able to make things larger.

Zoom good, font size increasing bad.

In your opinion.

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

Try setting your text container dimensions in em then.

Yes. As soon as you define everything in em these problems completely cease to exist.

Oh I take great pleasure in telling you then that I force all my fonts to Century Schoolbook.

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

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.

Immediately following the demo is the 'options' section where it shows you have full control of this.

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.

The line-height part of this is unnecessary / duplicates css behavior. No need to use px. Just set the line-height to the ratio you want in css.

   p { line-height: 1.45; }

and you're done.

Neat. In case anyone else is curious about this: http://meyerweb.com/eric/thoughts/2006/02/08/unitless-line-h...

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

What exactly makes you say 16pt is the standard font size?

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

cmd+ cmd+ cmd+ cmd+ cmd+

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

I was referring to the default font size in browsers.

At least for my Windows Chrome, the default font size is 16px, not pt. 16pt corresponds to roughly 20px on my (Windows default) settings.

Great for you! I am reading this comment at 16pt.

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.

Seems like a reasonable solution until vmin/vmax/vh/vw are more widely supported.

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.

> Ideally, the most legible typography contains between 45 and 75 characters per line.

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

Don't forget it has "Thresholds" param.

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.

This seems pretty cool but is an absolute nightmare for people like myself who require Ctrl + Scroll zoom all the time for accessibility.

I really hate when libraries blindly assume that you are going to be using jQuery and make zero mention of that as a dependency.

The file is named flowtype.jQuery.js and you call it with $(selector).flowtype();? What made you think it wasn't a jQuery plugin?

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.

> This is difficult to accomplish for all screen widths with only CSS media-queries.

Couldn't you do it with viewport units?

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.

different but cleaner readability trick for blocks containing text, with css: max-width:62em

Absolutely agree. This is the right way how medium to long block of text should be styled. Except 62ex, not em, IMO.

This seems to break browser zoom, so while it is a neat feature, it is not worth having at the cost of accessibility.

Seems like a decent idea. Though it seemed to have far too few characters per line on the low end of the slider.

Nice hack, but a accessibility failure. Now the users with poor sight can't increase the font size.

I had to bump the demo site up to about 200% to start to see increases, but was definitely able to increase the text size.

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!

Just getting started with CSS - Are there any "golden ratio" typography generators?

This is exactly what I've been looking for a number of times before but was too stupid to hack together myself. Makes sense to me.

simple, yet awesome

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.

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

Reply on news.ycombinator.com