Tag: Type

On Type Patterns and Style Guides

Over the last six years or so, I’ve been using these things I’ve been calling “type patterns” in my web design work, and they’ve worked out pretty well for me. I’ll dig into what they are and how they can make their way into CSS, and maybe the idea will click with you too and help with your day-to-day typography needs.

If you’ve used print design desktop software like QuarkXPress, Adobe InDesign, or CorelDraw, then imagine this idea is an HTML/CSS translation of “paragraph styles.”

When designing a book (that spans hundreds of pages), you might want to change something about the heading typography across the whole book (on the fly). You would define how a certain piece of typography behaves in one central place to be applied across the entire project (a book, in our example). You need control of the patterns.

Most programs use this naming style, but their user interfaces vary a little.

When you pull up the pane, there’s usually a “base” paragraph style that all default text belongs to. From there, you can create as many as you want. Paragraph styles are for “block” level-like elements, and character styles are for “inline” level-like elements, such as bold or unique spans.

The user interface specifics shouldn’t matter — but you can see that there are a lot of controls to define how this text behaves visually. Under the hood, it’s just key: value pairs, which is just like CSS property: value pairs

h1 {   font-family: "Helvetica Neue", sans-serif;    font-size: 20px;   font-weight: bold;   color: fuchsia; }

Once defined, the styles can be applied to any piece of text. The little + (next to the paragraph style name below) in this case, means that the style definition has changed.

If you want to apply those changes to everything with that paragraph style, then you can “redefine” the style and it will apply project-wide.

When I say it like that, it might make you think: that’s what a CSS class is.

But things are a little more complicated for a website. You never know what size your website will be displayed at (it could be small, like on a mobile device, or giant, like on a desktop monitor, or even on monochrome tablet, who knows), so we need to be contextual with those classes and have then change based on their context.

Styles change as the context changes.

The bare minimum of typographic control

In your very earliest days as a developer, you may have been introduced to semantic HTML, like this:

<h1>Here's some HTML stuff. I'm a heading level 1</h1> <p>And some more. I'm a paragraph.</p>  <h2>This is a heading level 2</h2> <p>And some more pragraph stuff.</p>

And that pairs with CSS that targets those elements and applies styles, like this:

h1 {   font-size: 50px; /* key: value pairs */   color: #ff0066; }  h2 {   font-size: 32px;   color: rgba(0,0,0,.8); }  p {   font-size: 16px;   color: deepskyblue;   line-height: 1.5; }

This works!

You can write rules that target the headers and style them in descending order, so they are biggest > big > medium, and so on.

Headers also already have some styles that we accept as normal, thanks to User Agent styles (i.e. default styles applied to HTML by the browser itself). They are meant to be helpful. They add things like font-weight and margin to the headers, as well as collapsing margins. That way — without any CSS at all — we can rest assured we get at least some basic styling in place to establish a hierarchy. This is beginner-friendly, fallback-friendly… and a good thing!

As you build more complex sites, things get more complicated

You add more pages. More modules. More components. Things start to get more complex. You might start out by adding unique classes and styles for every single little thing, but it’ll catch up to you.

First, you start having classes for special situations:

<h1 class="page-title">   Be <span class='super-ultra-magic-rainbow'>excellent</span> to each other </h1>  <p class="special-mantra">Party on, <em>dudes</em>.</p>  <p>And yeah. I'm just a regular paragraph.</p>

Then, you start having classes everywhere (most CSS methodologies even encourage this):

<header class="site-header">   <h1 class="page-title">     Be <span class='ultra-magic-rainbow'>excellent</span> to each other   </h1> </header>  <main class="page-content">   <section class="welcome">     <h2 class="special-mantra">Party on <em>dudes</em></h2>      <p class="regular-paragraph">And yeah. I'm just regular</p>   </section> </main>

Newcomers will try and work around the default font sizes and collapsing margins if they don’t feel confident resetting them.

This is where people start trying out margin-top: -20px… and then stuff gets whacky. As you keep writing more rules to wrangle things in, it will feel like you are “fixing” things instead of declaring how you actually want them to work. It can quickly feel like you are “fighting” the CSS cascade when you’re unaware of the browser’s User Agent styles.

A real-world example

Imagine you’re at your real job and your boss (or the visual designer) gives you this “pixel perfect” Adobe Photoshop document. There are a bunch of colors, layout, and typography.

You open up Photoshop and start to poke around, but there are so many pages and so many different type styles that you’ll need to take inventory and gather what styles can be combined or used in combination.

Would you believe that there are 12 different sizes of type on this page? There’s possibly even more if you also take the line-height into consideration.

It feels great to finish a visual layout and hand it off. However, I can’t tell you how many full days I’ve spent trying to figure out what the heck is happening in a Photoshop document. For example, sometimes small-screens aren’t taken into consideration at all; and when they are, the patterns you find aren’t always shared by each group as they change for different screen types. Some fonts start at 16px and go up to 18px, while others go up to 19px and become italic. How can spot context changes in a static mockup?

Sometimes this is with fervent purpose; other times the visual designer is just going on feel and is happy to round things up and down to create reusable patterns. You’ll have to talk to them about it. But this article is advocating that we talk about it much earlier in the process.

You might get a style guide to reference. But even that might not be specific enough to identify contexts.

Let’s zoom in on one of those guidelines:

We get more content direction than we do behavior of the content in different contexts.

You may even get a formal, but generic, style guide with no pixel sizes or notes on varying screen sizes at all!

Don’t get me wrong: this sort of thing is defintely a nice thought, and it might even be useful for others, like in some client meeting or something. But, as far as front-end development goes, it’s more confusing than helpful. I’ve received very thorough style guides that looked nice and gave lots of excellent guidelines for things like font sizes, but are completely mismatched with the accompanying Photoshop document. On the other end of the spectrum, there are style guides that have unholy amounts of specifics for every type of heading and combination you could ever imagine — and more.

It’s hard to parse this stuff, even with the best of intentions!

Early in your development career, you’d probably assume it’s your job to “figure it out” and get to work, writing down all the pixels and trying your best to make sense of it. Go getem!

But, as you start coding all the specifics, things can get a little overwhelming with the amount of duplication going on. Just look at all the repeated properties going on here:

.blog article p {   font-family: 'Georgia', serif;   font-size: 17px;   line-height: 1.4;   letter-spacing: 0.02em;   margin-bottom: 10px; }  .welcome .main-message {   font-family: 'Georgia', serif;   font-size: 17px;   line-height: 1.4;   letter-spacing: 0.02em;   margin-bottom: 20px; }  @media (min-width; 700px) {   .welcome .main-message {     font-size: 18px;   } }  .welcome .other-thing {   font-family: 'Georgia', serif;   font-size: 17px;   line-height: 1.4;   letter-spacing: 0.02em;   margin-bottom: 20px; }  .site-footer .link list a {   font-family: 'Georgia', serif;   font-size: 17px;   line-height: 1.4;   letter-spacing: 0.02em;   margin-bottom: 20px; }

You might take the common declarations and apply them to the body instead. In smaller projects, that might even be a good way to go. There are ways to use the cascade to your advantage, and others that seem to tie too many things together. Just like in an Object Oriented programming language, you don’t necessarily want everything inheriting everything.

body {   font-family: 'Georgia', serif;   font-size: 17px;   line-height: 1.4;   letter-spacing: 0.02em; }

Things will work out OK. Most of the web was built like this. We’re just looking for something even better.

Dealing with design revisions

One day, there will be a meeting. In that meeting, you’ll find out that the client and the visual designer decided to change a bunch of the typography. Now you need to go back and change it in 293 places in the CSS file. If you get paid by the hour, that might be great!

As you begin to adjust the rules, things will start to conflict. That rule that worked for two things now only works for the one. Or you’ll notice patterns that could now be used in many more places than before. You may even be tempted to just totally delete the CSS and start over! Yikes!

I won’t write it out here, but you’ll try a bunch of different things over time, and people usually come to the conclusion that you can create a class — and add it to the element instead of duplicating rules/declarations for every element. You’ll go even further to try and pull patterns out of the visual designer’s documents. (You might even round a few 19px down to 18px without telling them…)

.standard-text { /* or something */   font-family: serif;   font-size: 16px; /* px: up for debate */   line-height: 1.4; /* no unit: so it's relative to the font-size */   letter-spacing: 0.02em; /* em: so it's relative to the font-size */ }  .heading-1 {   font-family: sans-Serif;   font-size: 30px;   line-height: 1.5;   letter-spacing: 0.03em; }  .medium-heading {   font-family: sans-Serif;   font-size: 24px;   line-height: 1.3;   letter-spacing: 0.04em; }

Then you’d apply the class to anything that needs it.

<header class="site-header">   <h1 class="page-title heading-1">     Be <mark>excellent</mark> to each other   </h1> </header>  <main class="page-content">   <section class="welcome">     <h2 class="medium-heading">Party on <em>dudes</em></h2>      <p class="standard-text">And yeah. I'm just regular</p>   </section> </main>

This way of doing things can be really helpful for teams that have people of all skill levels changing the HTML. You can plug and play with these CSS classes to get the style you want, even if you’re the new intern.

It’s really helpful to separate the idea of “layout” elements (structure/parents) and the idea of “modules” or “components.” In this way, we’re treating the pieces of text as lower level components.

The key is to keep the typography separate from the layout. You don’t want all .medium-heading elements to have the same margins or colors. It’s going to depend on where they are. This way you are styling based on context. You aren’t ‘using’ the cascade necessarily, but you also aren’t fighting it because you keep the techniques separate.

.site-header {   padding: 20px 0; }  .welcome .medium-heading { /* the context — not the type-pattern */   margin-bottom: 10px; }

This is keeping things reasonable and tidy. This technique is used all over the web.

Working with a CMS

Great, but what about situations where you can’t change the HTML?

You might just be typing up a quick CodePen or a business-card site. In that case, these concerns are going to seem like overkill. On the other hand, you might be working with a CMS where you aren’t sure what is going to happen. You might need to plan for anything and everything that could get thrown at you. In those cases, you’re unable to simply add classes to individual elements. You’re likely to get a dump of HTML from some templating language.

<?php echo getContent()?> <?=getContent()?> $ {data.content} {{model.cmsContent}}

So, if you can’t work with the HTML what can you do?

<article class="post cms-blog-dump">   <h1>Talking type-patterns on CSS-tricks</h1>   <p>Intoduction paragraph - and we'd like to style this with a slightly different size font then the next (normal) paragraphs</p>   <h2>Some headings</h2>   <h2>And maybe someone accidentally puts 2 headings in a row</h2>   <ol>     <li>and some <strong>list</strong></li>     <li>and here</li>   </ol>    <p>Or if a blog post is too boring - then think of a list of bands on an event site. You never know how many there will be or which ones are headlining, so you have to write rules that will handle whatever happens. </article>

You don’t have any control over this markup, so you won’t be able to add classes, meaning that the cool plug-and-play classes you made aren’t going to work! You might just copy and paste them into some larger .article { } class that defines the rules for a kitchen sink. That could work.

What other tools are there to play with?

Mixins

If you could create some reusable concept of a “type pattern” with Sass, then you could apply those in a similar way to how the classes work.

@mixin my-useful-rule { /* define the mixin */   background-color: blue;   color: lime; }  .thing {   @include my-useful-rule(); /* employ the mixin */ }  /* This compiles to: */ .thing {   background-color: blue;   color: lime; } /* (just so that we're on the same page) */

Less, Sass, Stylus and other CSS preprocessors all have their own syntax for this. I’m going to use Sass/SCSS in these examples because it is the most common at the time of writing.

@mixin standard-type() { /* define the mixin */   font-family: Serif;   font-size: 16px;   line-height: 1.4;   letter-spacing: 0.02em; }  .context .thing {   @include standard-type(); /* employ it in context */ }

You can use heading-1() and heading-2() and a lot of big-name style guides do this. But what if you want to use those type styles on something that isn’t a “heading”? I personally don’t end up connecting the headings with “size” and I use the patterns in all sorts of different places. Sometimes my headings are “mean” and “stout.” They can be piercing red and uppercase with the same x-height as the paragraph text.

Instead, I define the visual styles in association with how I want the “voice” of the content to come across. This also helps the team discuss “tone” and other content strategy stuff across disciplines.

For example, in Jason Santa Maria’s book, On Web Typography, he talks about “type for a moment” and “type to live with.” There’s type to grab your attention and break up the page, and then those paragraphs to settle into. Instead of .standard-text or .normal-font, I’ve been enjoying the idea of organizing styles by voice. This is all that type that a user should spend time consuming. It’s what I’d likely use for most paragraphs and lists, and I won’t set it on the body.

@mixin calm-voice() { /* define the mixin */   font-family: Serif;   font-size: 16px;   line-height: 1.4;   letter-spacing: 0.02em; }  @mixin loud-voice() {   font-family: Sans-Serif;   font-size: 30px;   line-height: 1.5;   letter-spacing: 0.03em; }  @mixin attention-voice() {   font-family: Sans-Serif;   font-size: 24px;   line-height: 1.3;   letter-spacing: 0.04em; }

This idea of “voices” helps me keep things meaningful because it requires you to name things by the context. The name heading-1b, for example, doesn’t help me connect to the content to any sort of storytelling or to the other people on the team.

Now to style the mystery article. I’ll be using SCSS syntax here:

article {   padding: 20px 0;   h1 {     @include loud-voice();     margin-bottom: 20px;   }   h2 {     @include attention-voice();     margin-bottom: 20px;   }   p {     @include calm-voice();     margin-bottom: 10px;   } }

Pretty, right?

But it’s not that easy, is it? No. It’s a little more complicated because you don’t know what might be above or below each other — or what might be left out, because articles aren’t always structured or organized the same. Those CMS authors can put whatever they want in there! Three <h3> elements in a row? You have to prepare for lots of possible outcomes.

/* Styles */ article {   padding: 20px 0;    h1 {     @include loud-voice();   }    h2 {     @include attention-voice();   }    p {     @include calm-voice();      &:first-of-type {       background: lightgreen;       padding: 1em;     }   }    ol {     @include styled-ordered-list();   }    * + * {     margin-top: 1em    } } 

To see the regular CSS you can always “View Compiled” in CodePen.

Some people are really happy with the lobotomized owl approach (* + *) but I usually end up writing explicit rules for “any <h2> that comes after a paragraph” and getting really detailed. After all, it’s the written content that everyone wants to read… and I really only need to dial it in one time in one place.

/* Slightly more filled out pattern */ @mixin calm-voice() {   font-family: serif;   font-size: 16px;   line-height: 1.4;   letter-spacing: 0.02em;   max-width: 80ch;    strong {     font-weight: 700;   }    em {     font-style: italic;   }    mark {     background-color: wheat;   }    sup {     /* maybe? */   }    a {     text-decoration: underline;     color: $ highlight;   }    @media (min-width: 600px) {     font-size: 17px;   } }

Stylus

It’s nice to think about the “ideal” workflow. What could browsers implement that would make this fun and play well with their future systems?

Here’s an example of the most stripped down preprocessor syntax:

calm-voice()   font-family: serif   font-size: 16px   line-height: 1.4   letter-spacing: 0.02em  article   h1     loud-voice()   h2     attention-voice()   p     calm-voice() 

I’ll be honest… I love Stylus. I love writing it, and I love using it for examples. It keeps people on their toes. It’s so fast to type in CodePen! If you already have your own little framework of styles like this, it’s insane how fast you can build UI. But! The tooling has fallen behind and at this point, I can’t recommend that anyone use it.

I only add it here because it’s important to dream. We have what we have, but what if you could invent a new way of writing it? That’s a crucial part of the conversation too. If you can’t describe what you want, you wont get it.

We’re here: Type Patterns

Can you see where all of this is going?

You can use these “patterns” or “mixins’ or “whatever” you want to call them and plug and play. It’s fun. And you can totally combine it with the utility class idea too (if you must).

.calm-voice {   @include calm-voice(); }
<p class="calm-voice">Welcome to this code snippet!</p>

Style guides

If you can start to share a common language and break down the barriers between “creatives” and “coders,” then everyone can work with these type patterns in mind from the start.

Sometimes you can simply publish a style guide as a “brand” subdomain or directly on the site, like at /style-guide. There are tons of these floating around on the web. The point is that some style guides are standalone, and others are built into the site itself. Wherever they go, they are considered “live” and they allow you to develop things in one place that take effect globally, and use the guide itself as a sort of artifact.

By building live style guides with type patterns as a core and shared concept, everyone will have more fun and save time trying to figure out what each other means. It’s not just for big companies either.

Just be mindful when looking at style guides for other organizations. Style guides serve different purposes depending on who is using them and how, so simply diving into someone else’s work could actually contribute more confusion.

Known unknowns

Sometimes you don’t know what the content will be. That means CMS stuff, but also logic. What if you have a list of bands and events and you are building a module full of conditional components? There might be one band… or five… or two co-headliners. The event might be cancelled!

When I was trying to work out some templating ideas for Ticketfly, I separated the concerns of layout and type patterns.

Variable sized font patterns

Some patterns change sizes at various breakpoints.

@mixin attention-voice() {   font-family: Serif;   font-size: 20px;   line-height: 1.4;   letter-spacing: 0.02em;   @media (min-width: 700px) {     font-size: 24px;   }   @media (min-width: 1100px) {     font-size: 30px;   } }

I used to do something like this and it had a few yucky side effects. For example, what if you plug and play based on the breakpoints and there are sizes that conflict or slip through?

clamp() and vmin units to the rescue!

@mixin attention-voice() {   font-family: Serif;   font-size: clamp(18px, 10vmin, 100px);   line-height: 1.4;   letter-spacing: 0.02em; }

Now, in theory, you could even jump between the patterns with no rub.

.context {   @include calm-voice();   @media (min-width: 840px) {     @include some-other-voice();   } }

But now you have to make sure that they both have the same properties and that they don’t conflict with or bleed through to others! And think about the new variable font options too. Sometimes you’ll want your heading to be a little less heavy on smaller screens or a little taller to work with the space.

Aren’t you duplicating style rules all over the place?

Yikes! You caught me. I care way more about making the authoring and maintaining process pleasurable than I care about CSS byte size. I’m conflicted though. I get it. But I also think that the solution should happen somewhere else in the pipeline. There’s a reason that we don’t write machine code by hand.

Sometimes you have to examine a programming pattern closely and really poke at it, trying it in every place you can to prove how useful it is. Humor me for a movement and look at how you’d use this type pattern and other mixins to style a common “card” interface.

In a way, type patterns are like the utility class style of Bootstrap or Tailwind. But these are human readable. The patterns are added in the CSS instead of the HTML. The concept is the same. I like to think that anyone could look at the living style guide and jump into a component and style it. What do you think?

It is creating more CSS though. Those kilobytes are stacking up. But I think we should work towards something ideal instead of just “possible.” We can probably build something that works this out at build time. I’ll have to learn more about the CSSOM and there are many new things coming down the pipeline that could make this possible without a preprocessor.

It’s bigger than just the CSS. It’s about the people.

Having a set of patterns for type in your project allows visual designers to focus on their magic. More and more, we are building fast and in the browser. Visual designers focus on feel and typography and color with simple frameworks, like Style Tiles. Then developers can organize the data, resource structures and layouts, and everyone can work at the same time. We can have clearer communication and shared understanding of the entire process. We are all UX designers.

When living style guides are created as a team, there’s a lot less need for pixel-pushing. Visual designers can actually spend more time thinking and trying ideas in prototypes, and less time mocking out unnecessary production art. This allows you to work on your brand as a whole and have one single source of truth. It even helps with really small sites, like this.

Gold Collective style guide

InDesign and Illustrator have always had “paragraph styles” and “character styles” for this reason, but they don’t take into account variable screen sizes.

Toss in a few padding type sizes/ratios, some colors and some line widths. It doesn’t have to really be “pixel perfect” but more of a collection of patterns that work together. Colors as variables and maybe some $ thick, $ thin, or $ pad*2 type conventions can help streamline design patterns.

You can find your inspiration in the graphics program, then jump straight to the live style guide. People of all backgrounds can start playing with the styles in a CodePen and dial them in across devices.

In the end, you’ll decide the details on real devices — together, as a team.


The post On Type Patterns and Style Guides appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , ,

Just Dropping Some Type Links

I’ve had a bunch of tabs open that just so happen to all be related to typography, so I figured I’d give myself the mental release of closing them by blogging them. How’s that for a blog post format for ya: whatever random tabs you’ve had open for far too long.

  • Times New Roman is popular on the web in the sense that it’s a default font installed on most computers and safe to use without having to load any web fonts. But it’s also the default font that (all?) web browsers use if you don’t declare a font-family at all so, in that sense, it sometimes feels like a site is broken on accident when Times is used. Typewolf has a nice list of alternatives if you like the vibe but need something different.
  • Speaking of Times, err, The New York Times profiles TypeThursday with a pretty funny correction where they got the typeface name wrong.
  • In the last month of 2019, Tyopgraphica published their favorite typefaces of 2018. Fern grabs me.
  • Una Kravets has a “designing in the browser” video about typography on the Chrome Developers channel on YouTube. About 11 minutes in, she gets into variable fonts which are just incredible. I know they are capable of all sorts of amazing things (even animation), but I remain the most excited about performance: loading one font and having tons of design control.
  • Florens Verschelde’s “A short history of body copy sizes on the Web” gets into how typical font size usage has crept up and up over the years.
  • Alina Sava makes the argument that font licensing is ill. Primarily: pricing web fonts based on page views. As someone who works on some high-traffic / fairly-low-profit websites, it’s hard to disagree.
  • Matej Latin covers five fonts designed for coding that have ligatures. Ya know, instead of != you get , but only visually rather than actually changing the characters that are used as I did there. Ligatures are a neat trick to use (another trick: ligatures as icons), but Matthew Butterick says “hell no”: The ligature introduces an ambiguity that wasn’t there before. I find it notable that Operator Mono chose not to go there. I feel like I overheard a discussion about it once but can’t dig it up now. I know there is a way to add them, and it’s a little surprising to me that’s legal.
  • Trent popped some new fonts on his blog and shared his font shopping list.
  • You might have noticed some new fonts around here on CSS-Tricks as well, as of a few weeks ago. I just wanted to freshen up the place as I was getting sick of looking at system fonts (they started looking bad to me on Catalina, which is something Andy Baio pointed out is a Chrome Bug, but still). The CSS-Tricks logo has long been Gotham Rounded, so I went back to Hoefler&Co. for the font choices here to kinda stay in the family. The headers use Ringside, monospace content uses Operator Mono, and the body uses Sentinel.

The post Just Dropping Some Type Links appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]

Set Type on a Circle… with offset-path

Here’s some legit CSS trickery from yuanchuan. There is this CSS property offset-path. Once upon a time, it was called motion-path and then it was renamed. I sort of rolled my eyes at the time, because the property is so obviously for animating things along a path. But you don’t have to use it for animation, hence the rename, and this example proves it!

The thing with setting elements on a path though, is that the whole element is plopped on that path. So if that element is, say, <span>Chris</span>, that entire word is placed at a single point on the path. yuanchuan’s trick is to break the string into letters-as-spans, then place each span along the path (with a different offset-distance).

There is a top-of-circle path applied to each span:

offset-path: path('M 0 200 A 200 200 0 0 1 400 200')

Then there’s some fancy-dancing math (rather specific to this demo, of course) to calculate appropriate distances for each letter:

offset-distance: calc(8% + var(--n) * 89.5% / var(--total));

The beauty is that each span has its own custom property that affects the calculation. No big-chunk-of-:nth-child repetitive CSS is needed.

<div style="--total:14;">   <span style="--n:0">C</span>   <span style="--n:1">S</span>   <span style="--n:2">S</span>   <!-- ... -->

And it’s not just for letters! It’s good for all sorts of stuff!

Related notes:

  • This is way cleaner than an old method we blogged where each span had to use transform: rotate() with a common transform-origin point set down away from the letter itself.
  • SVG handles this without any hackery. (This isn’t totally a hack, but since you have to split into spans, you at least need to aria-label the parent, which then makes it feel hackier.)
  • Nitpick (I’m the worst): Don’t just make up HTML tags like this demo Pen on non-demo sites that people need to use.

The post Set Type on a Circle… with offset-path appeared first on CSS-Tricks.

CSS-Tricks

, ,
[Top]

The New Klim Type Website is Impossibly Lovely

I’ve spent the last hour hunched over the new Klim Type foundry website with my arms outstretched as if it was a fire in a very dark cave. Klim Type makes and sells wondrous fonts — like Tiempos, and National 2 or Pitch — and this fresh redesign now showcases them in all their glory. Here’s an example of the type specimen from the Calibre typeface:

There’s a shocking amount of beautiful design in this little website and I particularly like the blog where Kris Sowersby recently wrote a wonderful essay about the design of their latest type release, Söhne, which looks into the design of the New York subway signage, too:

Direct Link to ArticlePermalink

The post The New Klim Type Website is Impossibly Lovely appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]

Variations on Theme: Reinventing Type on the Web

If anyone knows anything about me, it’s usually one of two things: that I have two outrageously fluffy dogs, or that I like fonts and typography. Like, really really like them. So while I am super excited about how well Tristan is doing with his hydrotherapy —we’re walking 50% further than he was able just a couple months ago, without having to take breaks in the middle—I’m even more riled up about variable fonts.

Image of Tristan and Tillie explaining variable fonts

I know, you’re probably all really shocked.

I’ve been pretty single-minded about them since their introduction three years ago, and think they are going to be a massively Big Thing. But it just hasn’t gotten to that tipping point—yet. But a few things are coming together that make me think this just might be the year. Let me step back a bit and explain.

See the Pen
Variable font, outlined
by Jason Pamental (@jpamental)
on CodePen.

Plex Sans Variable, with outlines showing the range of weights and widths possible with a single file

The future is variable

Variable fonts are an evolution of the OpenType font specification that allows a single file to contain all of the variations of width, weight, slant, italics, and virtually any other permutation of a typeface the type designer want’s to expose—all in a single file. That one file is highly efficient, so it’s far smaller than all of the individual files. For the web, that means we can in many cases save considerable data download, reduce the number of HTTP requests, and in general vastly increase the design flexibility at our disposal. A pretty big change from those plain ‘ol static web fonts we’ve been using for the past 10 years. There’s loads of good stuff out there about them (I’ve written a few here, here, here, and here), but you can also browse the tag right here on CSS Tricks.

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

Chrome Opera Firefox IE Edge Safari
66 53 62 No 17 11

Mobile / Tablet

iOS Safari Opera Mobile Opera Mini Android Android Chrome Android Firefox
11.0-11.2 No No 76 78 68
Variable fonts are viewable by 87% of devices on the web according to caniuse.com.

Now that browser support is pretty complete (for the most part everything but IE11 and a couple of Android browsers like Baidu and UC), availability of variable fonts is improving (check out v-fonts.com), and Google is launching support for them via their new API—it feels like this might finally be the breakout year for them.

What excites me the most about that is what we’ll see people create. I’m sure at first it will be lots of “rip and replace”, similar to what we saw on the Nielson/Norman group site with their inclusion of Source Sans Variable on their site last year, or what Google has been testing with Oswald Variable on sites 148 million times a day for the past several months. Basically just using that instead of a few static instances to reap the benefits of faster page loads and less code.

Which is great, but only just a beginning.

What I’m looking forward to seeing is people embracing the full range of what these fonts can do. Going form ultra-light to super-heavy, super-condensed to extra-wide. Whatever the fonts support is there for us to explore. I’m hoping to see designers dive in and explore the power of great typography. Type that speaks more and varied volumes to help guide us around our sites and apps. Type set in motion that can lead us from here to there.

See the Pen
Layout variations, part deux
by Jason Pamental (@jpamental)
on CodePen.

This is one of the explorations I did for my newsletter and talks, playing with notions of legibility and the tension between reading fast and slow.

Will some of it be awful?

Probably. But so were a lot of early responsive websites. And lots of sites with static web fonts when they first launched. Or Flash-based sites. All of these have been evolutions of what we can design and make on the web. It’s up to us to do it well instead of poorly. I’m excited to learn together.

After all, if type is the voice of our words—with variable fonts—that voice has become a chorus.

The post Variations on Theme: Reinventing Type on the Web appeared first on CSS-Tricks.

CSS-Tricks

, , ,
[Top]