Continuous Typography(maxkoehler.com)
maxkoehler.com
Continuous Typography
https://maxkoehler.com/posts/continuous-typography/
40 comments
I would guess (from very little practical experience in this area) that you probably want to use "100%" for the main text, because, like you say, that's the user's preference and depends on things like how far away the user is from the screen and how good the user's eyesight is, which cannot be determined other than by asking the user. However, using "200%" unconditionally doesn't sound like a great idea because that might lead to lines with far too few characters in them. If you have a user who cannot read the text unless the font is so large that you only have about 20 characters across the width of the screen then you probably don't ever want to double the font size. (That might be a visually impaired user, but it could also be appropriate for a relatively small screen mounted in a public place.)
Little nitpick about the website: the math formula rendering likes to become invisible in Firefox[0]. Page reloads and reading mode tend to fix it but waiting a bit or doing some text selection will make it disappear again.
[0]: https://i.imgur.com/EGByvdA.png
[0]: https://i.imgur.com/EGByvdA.png
Why is this better than media queries? The user rarely drags the window edge back and forth, and if they do, they do it one time to resize the window.
"Parametric" is the word not "continuous", as in "parametric design": https://en.wikipedia.org/wiki/Parametric_design
https://www.danieldavis.com/a-history-of-parametric/
https://www.danieldavis.com/parametric-typography/
https://www.danieldavis.com/a-history-of-parametric/
https://www.danieldavis.com/parametric-typography/
I think the author point is that the different parameters are continuous with respect to the screen width, by opposition of just using media queries to go from 16px to 18px for example. And "continuous" is the right mathematical term for this.
I agree that "continuous" is a poor choice of word. Reading the article, it is clear that the author does not care about continuity in the mathematical sense of the term, but rather about allowing the design parameters to vary as a function of the user's environment parameters.
As mentioned in some other comment, a constant function is continuous but is obviously not what the article is about.
As mentioned in some other comment, a constant function is continuous but is obviously not what the article is about.
> The font size on paragraphs is equal to the width of the reader's screen multiplied by 0.01. That's a continuous function.
I was wondering how "discretely" to inform him of this.
I was wondering how "discretely" to inform him of this.
`font-size: 16px` is also a continuous function. I've been using «Continuous Typography» since I started web dev!
I'm after the point that continuous==analog, and therefore impossible on a digital system.
The demo given at the bottom helps you understand what this is getting at (it's desktop-only):
https://awesomephant.github.io/continuous-typography/
https://awesomephant.github.io/continuous-typography/
The demo should be the first thing on the page! It really gets to the point.
Pretty ironic that the demo is totally unusable on mobile.
How's that? It's an article about fluidly resizing typography based on viewport size: it would make sense that a [proof of concept] demo tool would be built to work in an environment where you can actually change viewport size. How could you possibly make use of the tool in an environment where you do not have the ability to do that?
Then what's the point of the demo? Dragging the edge of the browser window make type scale fluidly? Typically the user is at a fixed viewport size, or they change to one or two other ones when the window is resized.
But from a practical point of view, if you are building a design tool (which is what the demo is), and the purpose of the tool is to apply adjustments across screen sizes, it needs to be in an environment which allows for different screen sizes. The entire point is that you can adjust how the type scales based on viewport size: if you cannot scale the viewpoint size, the tool is effectively useless. The end target of the code produced by the tool is not the same thing as the environment the tool runs in. The vast majority of GUI design tools are for desktop, for what should be very obvious practical reasons.
Like, Adobe XD (to take one prototyping tool) doesn't work on mobile. You can view the end prototype on a mobile device, but the tool itself does not work in that environment, and it would make no sense for it to, the environment is too restrictive.
Like, Adobe XD (to take one prototyping tool) doesn't work on mobile. You can view the end prototype on a mobile device, but the tool itself does not work in that environment, and it would make no sense for it to, the environment is too restrictive.
[deleted]
Is it? I wouldn't say ironic, however I can see why you might reach that conclusion.
The demo isn't a representation of a productionised end product. It is a playground representating the findings of the authors article for desktop users; it simulates a dynamic window which you can resize using your mouse - so the demo not functioning properly on mobile seems acceptable.
The demo isn't a representation of a productionised end product. It is a playground representating the findings of the authors article for desktop users; it simulates a dynamic window which you can resize using your mouse - so the demo not functioning properly on mobile seems acceptable.
I like the graphs on this page - I wonder how they were developed
A combination of vw and vh were ultimately how I decided to tackle the problem. I'm very happy with the amount of control and flexibility I ended up with on my slightly design heavy website.
Https://magicseth.com/
Https://magicseth.com/
Viewport-relative widths are a poor practice for accessibility, in general (maybe you don't care for your small personal website). The user can't set their own preferred size, font-size becomes illegible at small sizes, and way too large on large viewports (2160px is becoming more common). It breaks zoom on some browsers as well.
The clamp() examples here mitigate that somewhat, but why do we need fluid shifts in text size? Just use media queries.
The clamp() examples here mitigate that somewhat, but why do we need fluid shifts in text size? Just use media queries.
Have you seen Stump the Guesser by Guy Maddin? Your site reminds me of it.
Wow I think this is a fantastic idea that feels pretty unexplored, still. I hope this might become so commonplace that one day we'll have css shortcuts for them, not unlike "ease-in" for transition timing and the likes. Combining the screen size and the user font size seems like a pretty great idea, especially!
It's been explored for years. Here's an article from 5 years ago: https://www.smashingmagazine.com/2016/05/fluid-typography/
Knuth tried this with METAFONT.
You are right that METAFONT allows a font designer to vary the font in a continuous way using parameters while retaining its essence. But this is addressing a different problem. It allows a document designer to adapt the font to the page.
I suppose this approach could be used together with the METAFONT approach so that the font itself varies as needed, too.... but my head hurts thinking about it.
I suppose this approach could be used together with the METAFONT approach so that the font itself varies as needed, too.... but my head hurts thinking about it.
CSS needs fewer font display options, not more. People have got drunk on text customization ("branding"), resulting in a web where no two sites read the same way. A few months ago I unticked "Allow pages to choose their own fonts, instead of your selections above" in Firefox, and I've not looked back.
> A few months ago I unticked "Allow pages to choose their own fonts, instead of your selections above" in Firefox, and I've not looked back.
I did the same, and I am still amazed at how impressively you can break website UIs with this simple setting. Want to absolutely wreck a modern responsive web app built by a billion-dollar IT corporation? Deny it custom fonts and everything comes crashing down:
https://i.imgur.com/LoudUCD.png
I did the same, and I am still amazed at how impressively you can break website UIs with this simple setting. Want to absolutely wreck a modern responsive web app built by a billion-dollar IT corporation? Deny it custom fonts and everything comes crashing down:
https://i.imgur.com/LoudUCD.png
For those interested in the source code for the example: https://github.com/awesomephant/continuous-typography
I've used a similar technique on sites for many, many years .. specifically using the calc function to define body-level font sizes (page dimensions ratios) for each breakpoint, which can then be used to size everything else on the page (eg. img = 16rem; margin = 2.4em). It works really well, and saves a lot of time with responsive design as you only need to consider each breakpoint / ratio change. I don't think it's a particularly novel concept though.
Someone call Donald Knuth
Does this result in text that does not change size with zoom? I've seen several sites where it is all but impossible to change zoom levels because the whole site resizes itself. This "feature" drives me nuts when I run into it ...
There are multiple ways to go about implementing "zoom" in browsers. You may be able to change this in a setting somewhere.
Nowadays the default way to do zooming is to pretend the entire page is being rendered at a different resolution than the real screen. You can view this in action by typing "window.screen" in your browser console, zooming, then checking that variable again (in Chrome check window.visualViewport).
Pretending here means the browser (if it's Firefox) lies to JavaScript and when computing the layout, but then scales pixel values back to real screen values before rendering. That's why stuff generally won't look pixelated[1].
[1]: A notable exception is canvas elements. Since a script may decide to use a lower resolution for them.
Nowadays the default way to do zooming is to pretend the entire page is being rendered at a different resolution than the real screen. You can view this in action by typing "window.screen" in your browser console, zooming, then checking that variable again (in Chrome check window.visualViewport).
Pretending here means the browser (if it's Firefox) lies to JavaScript and when computing the layout, but then scales pixel values back to real screen values before rendering. That's why stuff generally won't look pixelated[1].
[1]: A notable exception is canvas elements. Since a script may decide to use a lower resolution for them.
I think the actual problem that is being described is mostly solved by the device-independent pixel, where the size of `16 px` varies based on the device and doesn't actually correspond to 16 physical pixels (imagine that on a Retina display!).
I think the more interesting thing we should work towards is achieving metric typography—not just converting to millimetres, but actually measuring font-size based on x-height rather than total height.
I think the more interesting thing we should work towards is achieving metric typography—not just converting to millimetres, but actually measuring font-size based on x-height rather than total height.
No, it isn't. Physical pixels (as in, pixels being a physical measurement) decouple the pixel density from the size of the layout, so that things don't get smaller when you buy a higher-resolution monitor. What the article is talking about is changing the physically-valued font size to maintain, say, a particular line length.
For example, if you have a blog site, you probably want to have your content in one column with line lengths around, say, 50-70 characters. This is because very long lines are difficult to keep track of and short lines tire your eyes. But you also want your content to fill the screen.
If we had some kind of a constraint solver in CSS, you could say something like that and have the stylesheet resolve into something that changes the font size based on the viewport width, because that's the undetermined variable when you fix line length and box width. However, we don't have that, so the author instead has to explicitly say, "make the font size 1% the width of the viewport".
For example, if you have a blog site, you probably want to have your content in one column with line lengths around, say, 50-70 characters. This is because very long lines are difficult to keep track of and short lines tire your eyes. But you also want your content to fill the screen.
If we had some kind of a constraint solver in CSS, you could say something like that and have the stylesheet resolve into something that changes the font size based on the viewport width, because that's the undetermined variable when you fix line length and box width. However, we don't have that, so the author instead has to explicitly say, "make the font size 1% the width of the viewport".
Being able to supply any other units is a misfeature, in my opinion.