Continuous Typography

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

The demo should be the first thing on the page! It really gets to the point.

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.

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

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.

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?

This doesn't seem to work with Firefox. A blue splash fills the whole screen and stays there until I move my cursor outside the window or right click.

Have you seen Stump the Guesser by Guy Maddin? Your site reminds me of it.

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.

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

Knuth tried this with METAFONT.

It's been explored for years. Here's an article from 5 years ago: https://www.smashingmagazine.com/2016/05/fluid-typography/

> 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