Techniques for Responsive Typography

One of the most important aspects of responsive web design is responsive typography. When it comes to responsive type on the web, there’s more to do than just resizing the text’s container and having the text reflow inside of it. From choosing a font type and color, to achieving legible font sizes, line heights, and line lengths on different screen sizes, there are several ways to go about achieving fluid and truly responsive text on the web.

First Things First: Making text accessible

Before getting into techniques to resize text on different screen sizes, you need to make sure that your text is legible and accessible by using sufficient color contrast and an easily readable font to avoid turning your page’s content into an eye sore.

If text is not legible to begin with, then no matter how much you resize it, you’ll still end up with illegible text, which is of course the opposite of what you’re setting out to achieve in the first place. There are three points to consider to make sure your text is legible and accessible:

Choose A Readable Font Face

It is important when you choose a font face that you choose a readable one. Not all types of fonts are suitable for use as body type. Some fonts like artistic script fonts can be a great choice for short headlines, but when it comes to body type you need to make sure you choose a font that’s easily readable.

There are so many font styles to choose from, and services like Google Web Fonts and Typekit, among others, provide a long list of options to pick from, and both offer preview options which can help you make a better decision about which fonts to choose.

In addition, the @font-face rule in CSS allows you to use custom fonts in your page, and with pretty good browser support, you can start using it today, and provide a fallback font for browsers that don’t support it.

To define a font using the @font-face rule in the example below, we’re going to use Paul Irish’s bulletproof syntax.

Because of the diversity of formats supported by the browsers, you’ll need to create a font “kit” with at least three font files in order to get support across browsers: eot, woff, and truetype.

There are hundreds of free font kits available out there which contain all the file types you need in your @font-face, and if you want to use a custom font which you need to make your own kit for, you can always use Font Squirrel’s Font-Face Generator, which does an awesome job generating all you need to add your new font to your page, just make sure that the font you want to generate the @font-face for is legally eligible for web embedding and then you’re good to go.

/* Declare your font using the @font-face rule */
/* Source: http://www.paulirish.com/2009/bulletproof-font-face-implementation-syntax/ */
@font-face {
    font-family: 'Graublau Web';
    src: url('GraublauWeb.eot?') format('eot'), 
         url('GraublauWeb.woff') format('woff'), 
         url('GraublauWeb.ttf') format('truetype');
}

After you’ve declared your font, you can use it just like you would use any other font in your style sheet, and provide a fallback font for browsers that can’t read your custom font declared in the @font-face rule.

font-family: 'Graublau Web', 'Droid Sans', Arial, sans-serif; /* you can add any number of fallback fonts */

Browsers will display the first one they encounter on the list, so if a visitor is viewing your page in a browser that supports @font-face then they will see your custom font. If not they may see the fallback fonts you provided, and if all else fails they should be able to see your generic option.

Keep in mind that using too many font types in a page (not in the font rule above) can create a confusing visual layout, which is bad for all users, but may be especially difficult for users with reading disorders, learning disabilities, or attention deficit disorders.

Resources:

• A great @font-face 101 article on the ThemeForest Blog
• This article by Duncan Midwinter walks you through creating your own custom font using Font Squirrel’s Font-Face generator
• Paul Irish explains in his article why the above mentioned @font-face syntax is bulletproof

Font Color Accessibility

A website’s content is primarily there to be read, and low-contrast font colors can lead to text being unreadable. Don’t compromise high readability for beautiful comps. This is not just a design tip, this is a necessity when you’re creating content on the web.

W3C’s Web Content Accessibility Guidelines set the minimum contrast between text and its background so that it can be read by people with moderately low vision (which is quite common).

Another experiment confirms that reading time is lower when there’s high contrast between the text and the background. What’s more, contrast sensitivity declines with age.— Contrast Rebellion Website

Text is much easier to read when there is sufficient contrast between the text and the background. Low contrast and odd colors tend to look garish and be difficult to read even for those who are not colorblind, so it’s a good practice to ensure that text and backgrounds contrast strongly.

There are several tools out there to help you measure the contrast level of the colors you’re using for your designs, one of them is this tool which you can also use to find accessible color combinations, and which calculates the contrast in accordance with W3C’s Web Content Accessibility Guidelines.

To emphasize the importance of font readability and accessibility, and to also emphasize the fact that RWD is about more than just adapting layouts to different screen sizes, it’s worth mentioning that the W3C also introduced a new media query concept in the Media Queries Module Level 4, namely the Luminosity media query, among other new media features, which, if implemented, will allow designers and developers to adjust the style of the document in response to the ambient luminosity in which the device is used, to ensure maximum readability of the web page’s content. The user’s device must be equipped with a light sensor to trigger this new media feature.

Basically, the luminosity media query allows you to change the styles of your page inside a @media CSS rule, just like you normally do in regular media queries when you define new styles depending on the screen size, but in this case, you’d define new styles based on the value of the luminosity determined by the device’s sensor, which takes one of three values: dim, normal, or washed.

For example, to change the background and text color in different lighting conditions you’d write something like this:

/* Source: http://www.jordanm.co.uk/post/65776639602/responding-to-environmental-lighting-with-css-media */

@media (luminosity: normal) {
    body {
        background: #f5f5f5;
        color: #262626;
    }
}
@media (luminosity: dim) {
    body {
        background: #e9e4e3;
    }
}
@media (luminosity: washed) {
    body {
        background: #ffffff;
    }
}

Maybe you’re familiar with f.lux: it’s an application that makes the color of your computer’s display adapt to the time of day, warm at night and like sunlight during the day. Using the luminosity media query, you can change your page’s styles to adapt to outside lighting conditions in a similar way to what f.lux does, to make reading content on your web pages a lot easier on the eye.

We won’t be getting into details of this media query as this is still a working draft and not supported in any browser yet, but it was well worth mentioning to show that making text responsive is not restricted to changing its size on different screen sizes. Of course, the luminosity media query is not only used to style text in different lighting conditions, but it will be probably the most obvious use case for this query.

You can read more about the luminosity media query in this article by Jordan Moore, or in the W3C’s Media Queries Level 4 working draft.

Use “real” text rather than text within graphics

Text can be transformed into sound through the voice synthesizers in screen readers. Text can also be enlarged by screen enlargement or magnification software, without any loss of quality. These are the two main reasons why having content in text format is so important for accessibility. Although it is possible to provide alternative text for graphics, it is not possible to enlarge text in most graphics without some loss of quality (unless the graphic is vector-based, such as Scaleable Vector Graphics [SVG] or Flash, but this introduces a different set of potential accessibility problems).— Web Accessibility In Mind

When you’re creating responsive web designs that cater to different screen sizes and users, you also need to keep users with certain inabilities in mind and make sure they’re able to access your content as well. Responsive web design is about more than just adapting your website’s layout to different device sizes, it’s also about making sure your content responds to your users’ needs so that they can access it from any device no matter the context.

Now that we have the main font accessibility points covered, we’ll explore different ways to create fluid and responsive type on the web.

Making big headlines responsive

Using a jQuery Plugin

There are three fairly well known plugins out there for making big headlines responsive: FitText, BigText, and slabText. These three plugins make it possible to create big, bold, responsive headlines that fill the width of their parent element at any size.

Among these plugins, one that seems to have an advantage over the other two is the slabText plugin by developer Brian McAllister, which combines FitText with Erik Loyer’s slabtype algorithm for rendering text, to create flexible and scalable responsive headlines.

Put simply, the script splits headlines into rows before resizing each row to fill the available horizontal space. The ideal number of characters to set on each row is calculated by dividing the available width by the pixel font-size – the script then uses this ideal character count to split the headline into word combinations that are displayed as separate rows of text.— slabText Demo Page

Using the plugin is pretty straightforward. Supposing you have a heading that you want to be big and take up the full size of its container be fluid, all you have to do is include the plugin in your page, add some styles in your style sheet that are recommended in the plugin’s demo page (although I must say that I tried the plugin without these styles and it worked perfectly), and then call the plugin on your heading.

Here’s a demo using the slabText Plugin. You can have a look at the source for this demo by viewing the code in the HTML, CSS, and JS tabs. The code is pretty straightforward and self-explanatory. Try viewing the demo in full mode and resizing your browser window to see how the text size adapts to the size of the screen.

See the Pen Responsive Headline using the slabText Plugin by Sara Soueidan (@SaraSoueidan) on CodePen

And voilà! You have a fully responsive, fluid, big and bold headline that looks great on different screen sizes.

The BigText plugin by Zach Leatherman is also easy to use and straightforward. The BigText jQuery plugin takes a single element and sizes the text inside of its child <div>s to fit the width of the parent element.

Your markup would look like this:

<div id="bigtext" style="width: 300px">
    <div>The elusive</div>
    <div>BIGTEXT</div>
    <div>plugin exclusively</div>
    <div>captured on film</div>
</div>

And you just have to include the plugin source in your page and call the plugin on the parent element containing the text and the text inside it will be resized to fit its width at any size:

$('#bigtext').bigtext();

The plugin sizes text automatically from a base up to fit the element width, regardless of the initial font size.

Using CSS Viewport Units

An effect similar to that applied by the previous plugins can be also achieved using viewport CSS units: vw, vh, vmax, and vmin.

Using the viewport units allows you to make sure your text always fits into its container’s width, because the font size changes relative to the initial containing block, the viewport, which is the size of the browser window, and when its width changes, the font size changes as well. This sounds very similar to the way FitText and slabText above work, right? This is pretty cool considering that you can achieve the same effect the jQuery plugins achieve but only using CSS. Although, the results achieved by using these units are less flexible than those of the plugins, because fitText and slabText (and bigText) automatically expand the headings so they will fill up their container’s width on all rows, so they will still work if the amount of text in the headings changes, but it’s not the case when you’re using viewport units, as you’ll have to manually adjust the sizes for that.

The viewport-percentage lengths are relative to the size of the initial containing block. When the height or width of the initial containing block is changed, they are scaled accordingly.

1vw = Equal to 1% of the width of the initial containing block.
1vh = Equal to 1% of the height of the initial containing block.
1vmin = Equal to the smaller of ‘vw’ or ‘vh’
1vmax = Equal to the larger of ‘vw’ or ‘vh’.
— W3C Values and Units Module Level 3

When using these units with font-size, it’s one letter that takes that font size, but, and I quote Chris Coyier here, “as we know, in non-mono-spaced fonts the width of a letter is rather arbitrary. I find you just need to tweak around with the values to get it how you want it. Which is basically what we do anyway, right?”

Below is an example using viewport units to resize a heading. Similar to the previous demo, you can check the code out in the code panels of the embedded demo. Also, make sure you’re viewing this demo in a supporting browser. You need to be careful about browser support when you use CSS viewport units.

See the Pen Responsive Headline Using CSS Viewport Units by Sara Soueidan (@SaraSoueidan) on CodePen

You can see that some rows in the headline don’t expand to fit the width of the container, because there isn’t any algorithm applied to spread the letters and calculate the best number of letters on each row and then split the heading into rows like the slabText plugin did in the previous demo.

One thing to note here is that when the browser window is resized, the font doesn’t adjust itself according to the new viewport size, which is probably a bug. The font size changes to fit the size of its container if you refresh the page. To fix this issue (allow resizing without page refresh) you need to cause a “repaint” on the element.You can do that by following Chris Coyier’s example and using jQuery to cause a repaint. For the sake of getting the demo above to work, I used Chris’s snippet which changes the headline’s z-index on window resize, causing a repaint, and therefore you can see the headline adjust its size when you resize your browser as you view the demo.

If you want to read more about CSS viewport units, I suggest the following resources:

• Viewport-Sized Typography on CSS-Tricks
• W3C’s CSS Values and Units Specification
• CSS Viewport Units article by Opera Developers
• New Viewport-Relative Units article on the Treehouse Blog

Using Media Queries

The last and most commonly known way to make headlines responsive is by using the good ol’ media queries to define the font’s size on different screen sizes, using a set of defined breakpoints to adjust the font size accordingly. Of course, the result of this is the text size not being 100% fluid as in the previous techniques.

Supposing you have an level one heading in your markup, you can have it resize on different screen sizes using media queries like this:

body {
    font-size: 100%; /* start with a flexible baseline, more on this in the next section */
}

h1 {
    font-size: 2.5em;
}

@media screen and (max-width: 50em) {
    h1 {
        font-size:2em;
    }
}

@media screen and (max-width: 40em) {
    h1 {
        font-size:1.5em;
    }
}

@media screen and (max-width: 30em) {
    h1 {
        font-size:1.2em;
    }
}

It’s worth noting that it’s a best practice when you’re declaring media queries that you use em for setting your media query breakpoints, as using pixels will enact a horizontal scroll bar when you zoom in to the page and things don’t scale so well. Read more about proportional media queries on the Cloud Four blog. We’ll also go over why setting font sizes in em units is better than using pixels in the next section below.

Making body text responsive

When it comes to making body text responsive, there are some important notes to keep in mind. Not only do you have to resize the text to fit its container while maintaining excellent readability and reasonable line lengths, but you need to remember to preserve vertical rhythm with optimized and flexible line heights, make sure your text scales well on high-resolution screens, and can be easily resized by the user.

The above mentioned points can be achieved by making sure you’re using proportional and relative sizing units to size your font and define your line heights.

Using em and Media Queries

Ethan Marcotte, the guy behind the whole “Responsive Web Design” idea, wrote an excellent article on the Adobe Typekit blog explaining why using em (and rem, coming in the next section) is a lot better than using pixels to size your fonts.

Before diving into the benefits of using em to size text, it’s important to show why it’s a bad idea to use pixels. Pixels provide a high level of control over our text sizes, but it also comes with a well-known drawback: Text doesn’t scale up (or down) when you resize it in Internet Explorer, so there’s no way your reader will be able to increase the size of the font on your page if they want to when you’re using pixels to size it. “Now, it’s true that many desktop browsers, including more recent versions of IE, include some form of page zoom, which can magnify the size of your entire design, including its text. But older versions of IE are, alas, still out there.” Using em to size text, on the other hand, rids us of this problem altogether.

Moreover, it is recommended that you use a percentage value to set the font size for your page’s body, and start defining the content size proportional to this value. By declaring your body‘s font size in percentages, you provide a flexible baseline from which you can size the text up or down using relative units like the em. Setting the font size on the body to 100% sets the text size to the browser’s default font size, which is usually 16px.

A lot of developers tend to, or prefer to, use a baseline value of 62.5% on the body instead of a 100%, because the resulting font size applied to it will be an even 10px, and so it becomes a lot easier to define other font sizes on the page relative to this number, but it turns out that Richard Rutter, author of the original 62.5% technique, has written an article for A List Apart recommending 100% as a better baseline, one that ensures more consistent cross-browser results.

So, with this in mind, we can make our page type responsive using em and media queries. The simplest example would look like this:

body {
    font-size:100%; /* flexible baseline */
}

p {
    font-size: 1.25em; /* 1.25em relative to a 16px baseline on the body will result in a 20px font size */
}

To resize the font for smaller screens using media queries, it’s enough to just resize the body‘s font size, and because the page’s text is sized proportional to it, the entire text will also be resized, by changing just one line of CSS:

@media screen and (max-width: 40em) {
    body {
        font-size:90%;
    }
}

@media screen and (max-width: 30em) {
    body {
        font-size:80%;
    }
}

Now, we can’t achieve truly responsive type without maintaining a flexible line height for our content. Just like we need to make sure our text resizes nicely when the page is zoomed in or out, we need to make sure that the space between the lines is also resized and stays proportional to the new font size on every resize.

As you probably have guessed, line heights can also be defined in em instead of pixels as well. If we were to set our line heights in pixels, then if the reader decides to zoom the page up, for example, and the font size increases without increasing the line height, the space between the lines will remain small and the lines will become crowded and the vertical rhythm will be lost, making the text a pain to read.

Setting the line height in relative units also ensures that, as the text size becomes smaller on small screens, the vertical space occupied by the text also becomes smaller, which is kind of necessary on small screens which don’t have much vertical reading space to begin with.

A common value for line heights which is easily readable and easy on the eyes is a value of 1.4em for body text and 1.2em for headings. The values may change depending on the font face you’re using, but these are fairly common values. So, adding proportional line height values to the above rules we get:

body {
    font-size: 100%; /* flexible baseline */
}

p {
    font-size: 1.4em; /* 1.4em relative to a 16px baseline on the body will result in a 20px font size */
    line-height: 1.4em;
}

/* and if we have headings with defined styles we'd also add */
h1, h2, h3, h4, h5, h6 {
    line-height: 1.2em;
}

An even better, more flexible and more convenient way to set line heights is by using unitless values. Eric Meyer has written an excellent and very clear article explaining why it’s preferable that you set line heights in unitless values. Make sure you give it a read.

Some important notes:

1. It’s best that you use some kind of CSS reset when you define styles for your fonts, because browsers have predefined margins for headings and paragraphs that may interfere with the space you want to define between your lines.
2. When you work on your page’s vertical rhythm, you don’t want to forget to set an appropriate margin between paragraphs to ensure the vertical rhythm is maintained throughout your page copy.
   

   The default treatment by web browsers of paragraphs is to insert a top- and bottom-margin of 1em. In our case this would give a spacing between the paragraphs of 12px and hence throw the text out of rhythm. If the rhythm of the page is to be maintained, the spacing of paragraphs should be related to the basic line height unit. This is achieved simply by setting top- and bottom-margins equal to the line height.— Richard Rutter, Compose To a Vertical Rhythm, 24Ways Blog

3. In order to set the font sizes in em, there’s a simple rule to follow to determine the em alternative to a pixel value. Ethan Marcotte’s article on the Typekit blog explains how to calculate the font sizes in em clearly, so be sure to give it a read if you’re not familiar with it.

Using rem and Media Queries

Just like em, rem is also a relative CSS unit. It’s very similar to the em, except that the font size defined using rem is set relative to the font size of the root element, the html, instead of the body, and this is where the r in rem comes from, as rem stands for “root em“.

Sizing text with rem is pretty much the same as sizing it with em, with the same advantages, and one minor difference: you set a font size of 100% on the html element instead of the body, and then to resize your text in the media queries, you change the value on the html element just like we did above on the body element.

But if rem and em are so similar, then why use rem? What advantage does rem have over em?

The best thing about using rems is that you can size the text of your entire content in context of the root element, not in the context of its container.

For example, sizing nested lists using em can become really messy and cumbersome because of cascading:

If you decide that list items should be font-size: 1.1em and then have nested lists, it will cascade and grow the font size of the child lists. You probably didn’t want that. You can fix it with li li { font-size: 1em; } but that’s the kind of thing that can grind your gourd. That’s where rem‘s can come in, but that can be tricky as well since there is less browser support (IE 9+).— Why Ems? by Chris Coyier

Although browser support has become pretty reasonable, you may still want to provide fallback for older browsers in pixels, as falling back to em values will put you back into the em context complexity that you probably wanted to avoid the second you decided to use rem instead of em.

If you use a CSS preprocessor like Sass, which I totally recommend you do, you can use a mixin which will do all the fallback calculations for you. There are several mixins out there for rem, you can choose whichever one you prefer and start using rem in your project today.

Using rem is also preferable when you’re working on large-scale projects with lots of content and modules where keeping track of context and font size can get very tiresome, so using a relative unit that does not require any awareness of an element’s context is very convenient.

Using CSS Viewport Units

Using CSS viewport units to make body text responsive is done exactly the same way and for the same reasons mentioned in a previous section where we went over using these units to make big headlines responsive, so we won’t be going over this method again.

Using viewport units to resize body text has an obvious advantage over the previous methods using em and rem in that the text becomes 100% fluid, and does not depend on a set of media query breakpoints to resize; it will resize and fit to the size of its container no matter how or when the width changes.

You’ll see an example of using viewport units for creating fluid text in the next section.

Using a jQuery Plugin

At the beginning of this section we mentioned that when we “responsify” text content on a page, we need to make sure that the line length is easily readable as well. Line length is the number of words per line. Lines that are too long or too short can lead to a bad reading experience:

If a line of text is too long the visitor’s eye will have a hard time focusing on the text. This is because the length makes it difficult to get an idea of where the line starts and ends. Furthermore it can be difficult to continue from the correct line in large blocks of text.

If a line is too short the eye will have to travel back too often, breaking the reader’s rhythm. Too short lines also tend to stress people, making them begin on the next line before finishing the current one (hence skipping potentially important words).— Readability: the Optimal Line Length

A good line length is one that allows the reader’s eyes to flow from the end of one line to the beginning of the next very easily and naturally. The optimal line length for your body text is considered to be 50-60 characters per line, including spaces, and some folks say that up to 75 or even 80 characters is acceptable.

When resizing text to fit inside element widths on different screen sizes, we need to keep in mind that large-sized text on small screens will produce lines that are too short, and small-sized text on big or wide screens will lead to long lines of text with lengths exceeding the number of words recommended for best readability, therefore, in both scenarios, risking bad readability and consequently a bad user experience.

With that in mind, it’s best if we could find a way to decrease font size on small screens, and increase it on big screens, thus decreasing the number of words on big screens, and increasing them on smaller screens, to maintain a fairly reasonable amount of words for best readability. And it’s also best if we could achieve this text resizing automatically without manually setting font sizes in media queries, thus obtaining 100% fluid body text that, combined with relative line heights and a balanced vertical rhythm, can result in an optimal reading experience, or at least bring us closer to one.

CSS viewport units can help us achieve the fluidity we need to resize the text as the viewport’s width changes, but the problem is that the smaller the screen gets the smaller the font size will become, and it might end up being too small and unreadable on small screens, and too big on bigger screens, and there’s no way to set a minimum or maximum limit to the font size except by using media queries again, and setting a specific font size for screen sizes where the font may be too big or too small, and then there’s also browser support which also stands in the way of being able to achieve truly fluid type in all browsers.

Below is an example using viewport units to achieve fluid body type. As you resize the browser and the viewport width becomes smaller, the text becomes too small to read when you get to about 480px viewport width. I added a couple of media queries to adjust the size on small screen sizes and commented them so that you can initially see that the font keeps decreasing in size till it becomes unreadable. Uncomment the media query rules if you want to adjust the font size on smaller screens.

See the Pen Fluid Body Type using Viewport Units by Sara Soueidan (@SaraSoueidan) on CodePen

FlowTypeJS is a plugin that works on resizing the font size, and line height, based on a specific element’s width, thus resulting in fluid text like the viewport units provide, but of course has a couple of advantages over viewport units: cross-browser support, and options that allow us to specify minimum and maximum font sizes, so that text does not get bigger or smaller than we want it to.

Using the FlowType plugin is straightforward: you link to the plugin in your page, add some default font styles for users that don’t have Javascript enabled, and call the plugin on any element containing text content that you want to make fluid by the plugin, and customize it using the available options that come with the plugin. You can read more about the plugin’s options on its homepage.

Below is a fork of the above pen. Instead of using viewport units, I used the FlowType plugin as mentioned above and called the plugin on the paragraph of text which I added just for the sake of example, and in the plugin options I specified maximum and minimum font sizes for the text. Check out the code in the tabs below.

See the Pen Fluid Body Type using FlowTypeJS by Sara Soueidan (@SaraSoueidan) on CodePen

You can see how easy it is to achieve fluid body type using this plugin, without having to worry about adding any extra media query rules.

Using Element Queries

Element queries are similar to media queries in that, if a condition is met, some CSS will be applied. Element query conditions (such as min-width, max-width, min-height and max-height) are based on elements, instead of the screen. But the thing is, element queries don’t even exist yet in CSS. The concept of element queries spawned from an article written by Ian Storm Taylor, in which he explains how truly modular CSS can’t be achieved using media queries, and that being able to define breakpoints on an element rather than on the browser is a better way to build reusable elements with modular styles.

An element query would look similar to the following:

.main-nav (max-width: 30em) {
  font-size: 0.75em;
}

Following Ian’s article, another article on the topic was published on Smashing Magazine, and an element queries polyfill was introduced by Tyson Matanich.

The ElementQuery polyfill, on the other hand, uses a similar syntax to the above syntax by supporting the ~= attribute selector to check whether the value is contained in a space-delimited list. For example:

/* This rule queries itself for a single condition */
header[min-width~="500px"] {
    background-color: #eee;
}

/* This rule queries itself for multiple conditions */
header[min-width~="500px"][max-width~="800px"] {
    background-color: #eee;
}

Element queries are very useful in a sense that they allow us to define responsive styles for elements regardless of the “environment” or layout in which these elements exist. By defining modular styles for elements, we can reuse these elements and drop them anywhere and they will simply be able to adapt to the layout in which they are used.

For example, suppose you have a navigation and you want it to be responsive regardless of where it is placed other than the header. Instead of having to define styles according to its current container’s width, you could define its styles by querying the width of the navigation itself, therefore not having to take into account the margins, padding and other properties of the container, which you usually have to take into account when determining breakpoints for your content.

To make the navigation flexibly responsive and thus reusable, you could define its responsive styles depending on how its own width is changing. So it would be like saying: Regardless of where the navigation is put, whether in a wide header or a narrow sidebar, I want its links to float next to each other and have a font size of 1em when it is wide enough to contain its floated elements, for example when its width is greater than or equal 400px, and if its width is less than 400px, I want to have the navigation items stack on top of each other and decrease their font size to 0.8em.

So, you can see that this method is similar to the previous ones using em and rem with media queries, but it replaces media queries with element queries.

Tyson Matanich has created a collection of demos on Codepen showing how several elements can be made responsive using his ElementQuery polyfill. Below is a fork of one of his pens, which shows how a navigation’s styles change depending on its own width. Check the CSS tab out and fiddle with the code a bit to see how the navigation’s styles change based on its own width.

See the Pen Responsive menu using elementQuery by Sara Soueidan (@SaraSoueidan) on CodePen

Interactively Responsive Type?

A fairly new and rather interesting concept for “responsifying” text was introduced by Croatian web designer Marko Dugonjic, which uses face detection and a user’s webcam to resize text on a page based on the user’s proximity to the screen, which is an awesome idea, I must say!

Whether this method is practical or not, it’s definitely a creative and useful project that’s well worth mentioning when we’re tackling responsive typography. You can check out how this works on the project’s homepage. You need to have a webcam to see how it works.

The text in the demo is increased when you move farther away from the screen and is decreased when you move closer to it, maintaining a readable line length that does not exceed the recommended number of words as the text becomes smaller. Pretty neat, right? 🙂

Final Words

One useful way to check how your page’s type looks and works is by stripping your page of all kinds of images and media, and checking how your content looks without them. Does your text align well? Does it have a balanced vertical rhythm? Are your line lengths and type faces readable? What about hierarchy?

There’s an increasing tendency to believe that the responsive web will be 99.9% typography, and with the increasing “complexity” of today’s devices and the challenges they bring to responsive web design, a lot of designers are headed towards simpler layouts which focus mostly on typography, because, after all, the web content is there to be read first. Because of this, responsive typography is one of the most important aspects of responsive web design today.

Making your page’s typography readable and responsive isn’t hard, and is an important thing to do when you’re setting out to build responsive websites. I hope this article helped give you a range of techniques that you can choose from to “responsify” your type, and I hope you learned something new and found it useful.

Thank you for reading! =)