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.
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.
Why use anything other than percentage for font size? The browser sets the font size based on user preference. If you want text twice as big as usual, you make it font-size: 200%;
Being able to supply any other units is a misfeature, in my opinion.
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.)
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.
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?
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.
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.
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.
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".
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.
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!
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:
[+] [-] carapace|5 years ago|reply
https://www.danieldavis.com/a-history-of-parametric/
https://www.danieldavis.com/parametric-typography/
[+] [-] vbernat|5 years ago|reply
[+] [-] thorel|5 years ago|reply
As mentioned in some other comment, a constant function is continuous but is obviously not what the article is about.
[+] [-] smitty1e|5 years ago|reply
I was wondering how "discretely" to inform him of this.
[+] [-] muglug|5 years ago|reply
https://awesomephant.github.io/continuous-typography/
[+] [-] allenu|5 years ago|reply
[+] [-] emeraldd|5 years ago|reply
[+] [-] chmod775|5 years ago|reply
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.
[+] [-] hypertele-Xii|5 years ago|reply
Being able to supply any other units is a misfeature, in my opinion.
[+] [-] bloak|5 years ago|reply
[+] [-] somishere|5 years ago|reply
[+] [-] abelaer|5 years ago|reply
[+] [-] tfsh|5 years ago|reply
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.
[+] [-] RobertKerans|5 years ago|reply
[+] [-] magicseth|5 years ago|reply
Https://magicseth.com/
[+] [-] JxLS-cpgbe0|5 years ago|reply
The clamp() examples here mitigate that somewhat, but why do we need fluid shifts in text size? Just use media queries.
[+] [-] xwx|5 years ago|reply
[+] [-] nanna|5 years ago|reply
[+] [-] tester89|5 years ago|reply
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.
[+] [-] kmeisthax|5 years ago|reply
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".
[+] [-] alpaca128|5 years ago|reply
[0]: https://i.imgur.com/EGByvdA.png
[+] [-] skrebbel|5 years ago|reply
[+] [-] JxLS-cpgbe0|5 years ago|reply
[+] [-] andrepd|5 years ago|reply
[+] [-] csbartus|5 years ago|reply
[+] [-] JxLS-cpgbe0|5 years ago|reply
[+] [-] l0b0|5 years ago|reply
[+] [-] alpaca128|5 years ago|reply
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
[+] [-] mokash|5 years ago|reply
[+] [-] adultSwim|5 years ago|reply