Thanks Lori! Great question. Yes, legibility at viewing distance is the primary factor in selecting a good root level font size, and the recommended minimum font size is 16px for good legibility. But there are a few other factors that lead us to choose different font sizes, and why fluid typography is helpful.

You want to emphasize text to grab the readers attention first and lead them into other areas of the page. This is useful for headlines, pullquotes, or call to actions. To apply the most emphasis, you may want to make the text as big as possible. As big as possible may change depending on how much room there is available in the layout and at that viewport, as well as how long words tend to be in the language you are typesetting. But that covers why you might want to fluidly scale text to be bigger.

The reason why you might want to make text smaller is if words start to no longer fit in a layout. Text can start to break in awkward places, making it choppy to read, or worse, a word can overflow it’s container or the viewport. The Apple Watch automatically scales websites down to avoid this, as even 16px text will start to fall apart at that screen size.

I think Tim Brown gets to the core of your question in his post about Molten Leading. Yes, for paragraph text you don’t want to scale it up or down much. The two reasons I listed to scale text have more to do with headlines or extreme viewport sizes. However there are other considerations that you would want to take into account for paragraph text. Considerations like adjusting line-height fluidly to help people more comfortably track the lines of text they are reading. If you’re wondering, yes, this can be done with an intrinsic typographic approach. I use it to implement molten leading in my projects.

Thanks again for the question. I didn’t elaborate on it much in the article so I’m glad you gave me the opportunity here.

Thanks for reading Derek and I’m so glad you like the approach.

Ideally, we would be able to interpolate breakpoints natively in CSS. I’ll dive straight into the how as I think the article sums up why it would be ideal. Here is an issue with the CSS working group asking for breakpoint interpolation.

Animations can be re-mapped with JavaScript, and this is all the JavaScript does here. Using resizeObserver, a CSS custom property is written to all elements with the typetura class. The custom property is formatted as --tt-bind: 384 where 384 is the element width in CSS pixels. Now that we have a width to query in our CSS, we can hand that off to the animation function that is applied to all elements (at a low specificity so it can be overwritten). The animation function is animation:var(--tt-key) 1s var(--tt-ease) 1 calc(-1s * var(--tt-bind) / var(--tt-max)) both paused. In English, the keyframes, --tt-key, are applied starting at the position on the timeline corresponding to the width of the element, --tt-bind / --tt-max, and then paused there.

With the custom property written to elements and the foundational CSS in place, the CSS as described in this article will just work.

To expand upon this, you could query things other than element width, like scroll position, cursor position, or track viewing distance with TensorFlow. Then you can have that output to --tt-bind and style text off of it. Here is a non-typography and scroll based example that uses the same underlying CSS+JS technique.

Thanks for reading and your comment James! I’m a little unclear as to what you mean by transform scale being a solution to any of these problems. I’d love to see examples of what you’re doing with it.

We need less, not more complexity, and this type of code disguised as CSS just makes CSS harder to deal with.

Thanks Mark, I’m so glad you enjoy the article and concept!

Yes, I have a few thoughts here.

How I approach this now is I just don’t worry about the implementation when designing in Figma. Just like with responsive web design, we mock up static instances that are imperfect representations of the things we ultimately create. I find that I can reasonably accurately achieve what I have in my mockups with this approach. The sizing and spacing we define in our mockups tend to follow intuitive rules of proportion around constraints, and intrinsic typography is a way to create a map of that.

This still remains an unsatisfactory answer to your question. Making a parallel to responsive web design tooling, I still don’t think we have design tools that accurately represent our products. The idea that we have fixed art boards for fluid media is slightly absurd to me. Our first product at Typetura was app.typetura.com, that explored ways to visually typeset things, merging the concept of an animation timeline with viewport width. In the paradigm of our current tools, I made a quick prototype of what intrinsic typography might look like inside of Adobe XD. None of this is fully baked, but I think the future here is exciting.

What is exciting about the prospect of deeper integration with design tools for me is what it might mean for brand guidelines beyond UI pattern libraries. Grabbing a callout intrinsic type component and putting it into Photoshop to design a billboard, and using that same component for the marketing website, app, and magazine advertisement has the potential to really streamline production across all media a brand exists on.

Have you had any thoughts on how this could be worked into the design process? So if a designer were working on a new site design in figma how would they know what size the font should be at that set to based on the intrinsic typography constraints?

I would think if a desiger were just mocking up a single viewport then the styles could be set up to match the font size used in the design, but if they want to mock up multiple sizes (e.g. desktop, tablet, mobile) then they would need to know what size each text element would be scaled to at that size.

Scott, thank you for taking the time to give such a detailed reply. Yes, I agree now, this concept does make a lot of sense. Let´s see what can be build with it and keep up the good work!

Thanks for reading Ron!

While yes, you can style a container element, the reason I call this “intrinsic” is because the styles can respond to the properties of the element itself. For example, an H1’s font-size can change relative to the size of the H1 itself changing.

I feel like this meets the definition of intrinsic, or at least the spirit of it as no externalizes need to be considered in the styling.

In the CSS sense intrinsic behavior is styling; layout; etc. based on the natural internal qualities of a thing, whereas behavior based on the outside environment is called extrinsic behavior.

Typography which adapts to the available space is extrinsic typography.

The logical parallel here is CSS extrinsic and intrinsic sizing. Intrinsic sizing is sizing based on the size of the content itself – e.g. min-content and max-content. While extrinsic sizing is sizing dictated by how much space is available – e.g. stretch and contain from CSS Box Sizing Lv4.

Browser zooming and user set font size preferences are respected, so yes both forms of text zooming work as expected. Although you do have to use % and em/rem to respect user set font sizes. This can’t magically make font-size: 12px accessible to people

Note WCAG Success Criterion 1.4.4: Resize Text is the only thing to keep in mind, but that is a design issue not a technical issue as even sizing text with media queries can violate it. Issues have been opened and it will likely be amended to be more inclusive of typographic design changes at different dimensions. Also I have seen different interpretations, and as long as you can scale text by 200% with a 500% zoom level, SC 1.4.4 passes. Just something to keep in mind.

Thanks for reading Rob!

I haven’t run into the issues you are outlining, but can understand the concern. For the most part, headlines and pullquotes are what I style to be styled based on their own sizes, while other elements are styled based on parent or viewport contexts. In practical use, headlines are almost always scaled and styled based on layout differences, this approach can encapsulate all those disparate styles into a single intrinsic style. In these demos I have seen an estimated typographic CSS reduction of 75%-90% with nearly identical, but now fluidly responsive, typographic hierarchy. At this time I can’t make any of those 1:1 comparisons of large websites public so I understand your skepticism.

Also yes, you can, and I do, interpolate spacing with this approach. I tend to avoid systems like the 8pt grid as I find them more useful for the designer than something that provides a consistent experience for the reader. In terms of consistency, I focus on consistency of proportion and create tooling to control proportion as opposed to consistency of specific measurements used. I find this focus on proportion helps me design better experiences for fluid media, where I can’t expect a browser window and percent based layout to adhere to fixed measures I use when designing.

This is a new approach and I would love to see more real-world examples as well. Hopefully many examples will come in time.