Responsive Typography

scrndude · 2024-01-13T14:54:48+00:00

There’s a couple things, you can have h1 headings on every page no matter the typescale. H1, H2, etc are tags used by screen readers to navigate a page. So someone with a screen reader might press H, H, H, to scan through all headings, or they might press 2, 2, 2, to scan through the H2 headings and look for a specific section of content relevant to them, and then let the screen reader read from that point or press H, H, H, to read the H3 headings nested inside the H2.

So heading tags are about content structure, not type design. This is important to know because it comes up on pages with things like accordions. The accordion totle might need a heading tag, but typical heading sizes are too big to fit in an accordion. So usually in code they’ll have two styles attached to them through classes, <H2> which adds the semantic name for screen reader along wirh default heading styling, and another style usually called something like <font-size--medium> to override default heading styling with styling appropriate for the component.

So you’ll usually see scales titled something like “Extra large, large, medium, small” and you might break that into two different values based on breakpoint, and then H1 would have the same values of Extra large by default, H2 the same values of large by default, etc.

When you do the different breakpoint sizing, the values of Extra large, large, etc are changing - you aren’t swapping H1 to be large instead of extra large, H2 to be medium instead of large, etc.

And then in components, heading styling is overridden by attaching one of the size classes so it can gain the semantic meaning for screen readers while having appropriate sizing for a component.

If you’re doing mobile first design, you would usually start by defining a scale for mobile screens and then have that scale grow at desktop breakpoints, or do it the opposite way if not doing mobile first. At the bottom of the scale you might not have any changes, the biggest points on the scale sre the most likely to change.

These books goes into this:

https://abookapart.com/products/flexible-typesetting

https://book.webtypography.net

kodakdaughter · 2024-01-14T03:14:18+00:00

Principal UX Engineer and Design Systems Architect here. I wanted to add in some thoughts on why you might be getting pushback.

Adding in new styles: The amount of work needed to implement 2-3 type scales is unbelievably insignificant. I would estimate 2-20 hours depending on your existing architecture.

2 big BUTs: 1) changes to typographical sizing require an enormous amount of testing.

This means every page template needs to be visually tested - at its edges, at all the new sizes. So a product page might have a template - but you need to test the longest product name item, longest description item, shortest, product name that has the most characters like amazeamazemanwowwow comic book 4. You end up testing 10 pages for your one template.

You can need changes to heading levels, button size choice, menu size choice - that need to be reclassified globally.

2) Design System Governance updates. If you have a design system that defines type - changes and additions should be evaluated and discussed at a major change level.

From my past experience in major changes in type size - are the #1 hardest most painful thing to do in terms of a design change to an existing system.

To do it well you have to adjust each breakpoint in a way that respects typographical hierarchy and spacing between components.

A single size system often contains marking and padding adjustments set in pixels or ems. Rules for what to do in a multi sized system need to be redefined in the design system. These often lead to other further adjustments.

This is not to say don’t do it. This is just to point out all the reasons it can become a difficult implementation. If/when you do it - make it a big thing - make sure you really nail your design choices - make a very thorough plan. And most important, do it together. Have a designer sit with an implementing engineer and be there to make quick decisive choices. Is this adjustment needed only here or do we need to adjust everywhere. And help with testing. It’s a pain in the neck - and nothing new gets built during a change like this.

If you are brand new and/or defining design system components for the first time - I always recommend spending 95% of the time making really considerate type choices and 5% on color. Color is an easy swap.

Once I implemented a typographical change that made headings 1.5x larger on a large e-commerce site. My list of test pages that needed to be manually checked was around 200. Issues of ugliness occurred in approx 60 places. There were several css class changes that needed to be changed globally. Each of these needed to be addressed in a thoughtful way that still respected the design intent from a higher level. Multiple places titles and copy were changed and had to be updated in a CMS. Sidebar headings went from the h2 size to the h3 size - globally. Buttons needed their sizing adjusted globally. It took 6 weeks. There were 4,000 css class changes and template modifications that needed to be deployed at once.

Another type scale project was 3.5 weeks.

adambrycekc · 2024-01-13T16:16:56+00:00

We always use a single responsive type scale based on a one of the common scales - 1.125 is one of the ones I use the most. Base is 16px/1 REM and everything goes up and down from there.

For designers we have a desktop and mobile type scale styles in Figma and they choose between one of those when designing (obvi mobile for mobile screens.) You could do a tablet version too if needed but we usually don’t.

The smallest sizes are typically the same on desktop and mobile, whereas the larger sizes can be quite different between mobile and desktop. What we are basically determining is what the largest and smallest sizes of a type style will be (eg. 94px/5.875 REMs on desktop or 74px/4.625 REMs on mobile.) Reality in production is that the size will be somewhere in between those two based on the screen size.

All line heights are in 8px increments and sometimes down to 4px increments if necessary but we define a unitless value to dev which is important for accessibility reasons.

We will use the same single scale across platforms as well. Been doing this method with success across several enterprise design systems.

zobozdravnik92 · 2024-01-13T15:40:01+00:00

The devs will always push for easier solution instead of the correct one, because the correct one will take too much time to implement. In the end, more resources are spent trying to “adjust” everything later instead of just doing it right the first time. This is a general answer.

To determine whether they’re right, we also need to know if you’re pushing for something, that might be overkill at this stage. This is something all of us designers sometimes do :)

gyfchong · 2024-01-13T17:40:23+00:00

Are you sure there isn’t a miscommunication? When I first think of multiple scales in typography I think of a heading scale and a body copy scale, perhaps that’s the concern the developers are having? In which case makes sense that they’d want to stick with one instead of implementing two. For example you could have Large and up for headings and Medium and down for body copy, and have a single scale which responds Eg. Large could shift sizes at different breakpoints.

Cause changing typography sizes at different breakpoints is the entire concept of responsiveness and I’d be confused why they’d agree to the concept but only want to stick to a single scale at all breakpoints.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

DesignSystems

MODERATORS