
FlowType: font-size and line-height based on element width - aadlani
http://simplefocus.com/flowtype/
======
crazygringo
_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.)

~~~
dmarusic16
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.

~~~
indubitably
Yes, those silly people with bad vision.

~~~
jonny_eh
Zoom good, font size increasing bad.

~~~
ris
In your opinion.

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

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

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

~~~
eli
Neat. In case anyone else is curious about this:
[http://meyerweb.com/eric/thoughts/2006/02/08/unitless-
line-h...](http://meyerweb.com/eric/thoughts/2006/02/08/unitless-line-
heights/)

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

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

~~~
akx
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.

~~~
ohwp
I was referring to the default font size in browsers.

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

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

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

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

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

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

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

~~~
wiradikusuma
Don't forget it has "Thresholds" param.

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

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

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

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

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

Couldn't you do it with viewport units?

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

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

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

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

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

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

~~~
adamesque
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.

------
Rygu
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!

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

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

------
ozh
simple, yet awesome

------
monsterix
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...](https://bubbleideas.com/letters/the-tiger-by-sir-william-blake)

