
Precise control over responsive typography - kaishiro
http://madebymike.com.au/writing/precise-control-responsive-typography/
======
chrismorgan
Excerpt from a personal page I’m in the process of writing:

    
    
        :root {
            /* We wish to make the width range 768..1400 correspond to font-sizes 16..24.
            To convert this to the form font-size: calc(x * 100vw + y),
            we solve the simultaneous equation 1400 * x + y = 24, 768 * x + y = 16
            This comes to x = 1 / 79, y = 496 / 79. So, */
            font-size: calc((100vw + 496px) / 79);
        }
    
        /* min-font-size: 14px; */
        @media (max-width: 610px) {
            :root {
                font-size: 14px;
            }
        }
    
        /* max-font-size: 24px; */
        @media (min-width: 1400px) {
            :root {
                font-size: 24px;
            }
        }
    
        /* One extra rule: if the screen isn’t tall enough (arbitrarily selected to be 768px high), cap that font-size at 20px (which would by the earlier formula be reached at width 1084px (20*79-496)).
            Ideally we’d use a font-size rule factoring both vw and vh into it, but that kind of stuff takes too much thought for me at the moment. Yes, dear reader, I am lazy. Can you credit it? */
        @media (max-height: 768px) and (min-width: 1084px) {
            :root {
                font-size: 20px;
            }
        }
    

I’ve been contemplating replacing the last one with an aspect-ratio query, a
technique that occurred to me later for something in the arrangement where I
really needed it.

Still, with all of this sort of fanciness, I find myself _so_ much missing
min(), max() and broad custom properties support. ( _Especially_ the latter.
People may think their preprocessor variables cover all they need, but they
are _utterly_ wrong. They are an _amazing_ tool for more responsive design,
making advanced techniques which are agony at present—and thus typically
skipped, leaving “responsive” mostly very boring and clumsy—easy and logical.)

I really wish I could do the first three like this:

    
    
        :root {
            font-size: max(14px, min(calc((100vw + 496px) / 79), 24px);
        }

~~~
david-given
I found myself wanting to do precisely your last example not long ago. I
hadn't thought of using min-width and max-width media selectors to fake min
and max; that's really neat.

...I wonder if a CSS preprocessor could implement min and max using this
technique?

 _Edit:_ d'oh, this is precisely what the article was talking about!

~~~
pygy_
There's also this SASS mixin: [http://www.adrenalinmedia.com.au/the-
agency/insights/this-ch...](http://www.adrenalinmedia.com.au/the-
agency/insights/this-changes-everything-css-fluid-properties.aspx)

The linear equation solver is there, but it assumes px, and there's no
license...

------
callumlocke
I like this approach. One small wrinkle (especially when talking about
precision) is that many fonts optimise for the pixel grid at small type sizes,
so 15px vs 16px vs 17px can look like completely different typefaces (on non-
retina screens). Sometimes, this kind of variation in character can impact the
look of the page more than imprecision over viewport–type size ratios – the
latter is usually just a matter of having variable width margins, which is
rarely a problem. I think using absolute px sizes gives designers a feeling of
control for this reason. Then again, forcing a preferred glyph set by setting
a hard px size is (a) only applicable if you're using fairly small type sizes,
and (b) probably gives you a false sense of security anyway – it's all going
to change the moment someone zooms their browser, or uses a weird OS, or any
number of other things. I think I mostly agree with the author.

------
hammock
Viewport units, pixel units - all of these sidestep what the actual unit ought
to be relative to: the physical size of the screen (adjusted for how far away
it is from your eyes).

If I'm holding a 6 inch tablet, or a 9 inch tablet, both 2 feet away from my
face and with potentially different ppi, there's no reason for the 9 inch
tablet to have 50% larger font size.

Declaring size relative to pixels solves this only when PPI is constant.

~~~
Chris_Newton
Actually, CSS does already work almost the way you described. For devices
where the anchor unit is px, a CSS length of 1px is not defined in terms of a
single physical pixel on a screen but is instead an angular unit.

More specifically, in CSS 2.1, a “reference pixel” has an angle that
corresponds to one physical pixel on a 96dpi display at a nominal arm’s length
distance of 28in. A measurement of 1px is then recommended to refer to the
whole number of device pixels that best approximates the reference pixel.

In principle, that means whether you’re holding a phone or tablet with a
Retina-class display relatively close, looking at a traditional large format
desktop screen with fewer pixels-per-inch, or looking at a projected screen
from a typical viewing distance in a lecture theatre, sizing in terms of px
should still have approximately the same effect.

However, you do still have a difference of up to 1/3 of the nominal size to
contend with: a browser running on a device where a physical pixel is around
150% the size of a nominal reference pixel has to choose whether to use 1 or 2
display pixels for each px, resulting in output that is either 2/3 or 4/3 of
the theoretical ideal size.

I’ve been assuming this is part of the reason we see so many blogs currently
displaying irritatingly large body text if they’re viewed on a desktop or
laptop screen: the designers found that a more traditional font-size was too
small for comfortable reading on whatever mobile device they were using at the
distance they prefer to hold it, so they increased it.

For more on the CSS px definition, you can check the W3C spec:

[https://www.w3.org/TR/CSS21/syndata.html#length-
units](https://www.w3.org/TR/CSS21/syndata.html#length-units)

~~~
hammock
Awesome, thanks! Yes, angular unit is what I was fumbling for.

------
supergreg
The issue seems to be smooth scaling as the viewport size changes, but does
anyone resizes their browser window that way? I either click the maximize
button and it goes from, say, 800 to 1600px or flip my phone and it goes from
720 to 1200px instantly. I don't care if it's smoothly interpolating from one
size to the other.

~~~
JonathonW
But the sizes you're switching between are different for every user.

The goal here is to adjust font size appropriately for users with different
viewport widths. The interactive smooth-scaling effect that you get when drag-
resizing the browser window is nice, but it's a side effect, not the actual
goal of the technique.

------
kaishiro
A demo of the proposed technique:
[http://codepen.io/MadeByMike/pen/YPJJYv?editors=110](http://codepen.io/MadeByMike/pen/YPJJYv?editors=110)

