Complexity

Frank Chimero published a new talk-turned-essay, Everything Easy is Hard Again.

May we all be as wonderfully self-reflective and eloquent as Frank one day. There is a lot there, so please read it. Part of the theme is that web design and development has seemingly repetitive cycles that can kick even quite experienced people back down the ladder:

I don’t feel much better at making [websites] after 20 years. My knowledge and skills develop a bit, then things change, and half of what I know becomes dead weight. This hardly happens with any of the other work I do.

And complexity is to blame.

Complexity is one of those in the water topics right now. Kevin Ball wrote “we are in the midst of a massive and rapid period shift in complexity from the backend to the front.” Roneesh just celebrated untangling all this front end complexity in his own mind and shared his thoughts.

I’ve read a good number of responses to Frank’s article as well. I particularly liked our own Robin Rendle’s from the newsletter:

I believe the reason for all this complexity and nuance in the work is because we no longer expect the web to be a series of simple, hyperlinked documents.

Our expectations, as users of the web, have now completely changed.

Websites are machines in and of themselves; they have state, notifications, alerts and warnings, components that appear under certain circumstances, location-aware features and complexity beyond anything we were building fifteen years ago. There are more devices and viewport widths rendering our websites with increasingly difficult performance requirements.

That feels right to me. It’s just what I was feeling when I wrote What is the Future of Front End Web Development?

What websites are being asked to do is rising. Developers are being asked to build very complicated things very quickly and have them work very well and very fast.

Though, Frank points out that even layout, fonts, and images have ballooned in complexity. The cause there I’d argue is the rightful focus (and really, demand for) performance. But reactions to complexity are usually those things plus a dozen or two other things.

Perhaps things didn’t get complicated for no reason, and instead got complicated to compete. The web can do more, so we ask it to do more.

It’s tempting to think that the complexity comes entirely from that moreness. Embracing more of the potential of the web, playing catchup with native apps, and building more powerful tools for people. But I’m sure the whole story is more (ahem) complicated. Someone once told me the reason they think developer tooling has evolved and gotten more complicated is that developers generally aren’t asked to innovate on the business and product side. They build what they are told to, so they use their smarts to innovate on their own tools.

It depends though. A few personal examples.

I’ve been running CSS-Tricks for over a decade. It’s a garden variety WordPress site, and while it’s certainly evolved, it’s not all that much more complicated today as it was in the first few years. I’ve gotten better at working on it, in part because it’s changed so little that I’m more comfortable doing that work. I know just what all the spinning gears do and just where to put the oil, most of the time.

On the other hand, through CodePen, I’ve experienced a long product development which started fairly simple and has come to extreme complexity. We sometimes question if we’ve overdone the complexity, but for the most part, each step in that direction has been a response to make something else, ironically enough, less complicated. One example of that was the adding of React’n’Redux’n’Friends, which was a step up in the complexity of the development workflow, build, and deploy processes but, believe it or not, was a step down in a complexity of the codebase. These tools help us build faster, debug easier, stay well tested, and provide a performant experience, to name some of the benefits. We didn’t add tooling just for kicks; we added tooling because we had growing problems to address.

Not everyone has the same problems. The web is a big place is a phrase I see thrown around sometimes, and I like it. Over a billion websites, they say. A big place indeed.

Check out Dan Cederholm’s favorite website:

It’s not responsive. It’s not optimized for iPhone. It looks blurry on a Retina display. It doesn’t use the latest HTML5/CSS3 framework. It doesn’t have a thoughtful vertical rhythm. The fonts are nothing special. It is neither skeuomorphic nor flat. It doesn’t have its own favicon. It doesn’t have a native app or Twitter or Instagram. It doesn’t use AJAX or SCRUM or node.js or Sinatra. It doesn’t have an API or an RSS feed or VC funding. It hasn’t been featured on a prominent tech blog or won an award.

It tells me the soups of the day.

I suspect it doesn’t need any more complexity, and literally nobody is advocating it does. That’s why that the web is a big place sentiment is so useful. We talk about complexity, but it’s all opt-in. A wonderfully useful (and simple) website of a decade ago remains wonderfully useful and simple. Fortunately for all involved, the web, thus far, has taken compatibility quite seriously. Old websites don’t just break.

I’ll bet the bits in Frank’s essay about web layout will strike a chord to many readers of this site. Frank makes the connection between table layout and grid layout. It’s not a rare sentiment. For example:

I’m sure Frank understands the benefits of the new grid layout (e.g. try re-arranging a <table> at a media query breakpoint), but the sentiment was more about cycles than a deep technical dive.

I’d say a reasonable argument could be made that, with CSS in particular, things are easier these days. CSS of old had us biting our fingernails about cross-browser support, scattering vendor prefixes throughout our code, and (lol) saying a prayer to the box model. Eric Meyer, despite publishing a heavy tome of CSS knowledge lately, says:

CSS has a great deal more capabilities than ever before, it’s true. In the sense of “how much there potentially is to know”, yes, CSS is more of a challenge.

But the core principles and mechanisms are no more complicated than they were a decade or even two decades ago. If anything, they’re easier to grasp now, because we don’t have to clutter our minds with float behaviors or inline layout just to try to lay out a page.

Swinging it back to developers innovating on their own tools for a moment, another consideration is the impact of site builders on our industry. I’ll always recommend a site builder app in the right circumstances. Does your photography business need a portfolio site? Your bakery a homepage? Your custom scarf site a blog and eCommerce site? Assuming this is a sub-$10,000 job, I’d rather see you use a specialized site builder product than hire out the job to anyone who is going to build something entirely custom. I don’t wanna go too far down that rabbit hole, but suffice it to say, because I’m not alone in that thinking, the market for low-end custom design and development work is rather gone.

There are more developers these days working on in-house teams or agencies with big-ticket clients. That is, more and more developers on large-scope, long-scale, highly-complex jobs. So that’s where their minds are at. Big complicated problems with big complicated solutions. That’s what gets talked about. That’s what gets blogged about. That’s what gets argued about. That’s the topic at a lot of conferences I’ve been to.

While you certainly can make a soup-of-the-day website with an index.html file and FTP, blog posts about that are fewer and farther between and don’t get as many claps.


Shout out to Dave Rupert, my friend and ShopTalk Show co-host, who’s been pushing back against complexity in all its forms for as long as I’ve known him. I’m still trying to catch up.


Complexity is a post from CSS-Tricks

Understanding Web Fonts and Getting the Most Out of Them

Thierry Blancpain is a brand and interaction designer at Informal Inquiry in New York City and co-founder of Grilli Type, a Swiss type foundry. While this article is generally applicable to all web fonts, Grilli Type fonts are used throughout as examples of the concepts, particularly those demonstrating OpenType features.

Using your own fonts instead of system fonts is getting easier, but it’s still an evolving field. We’ll go over the different types of font formats and cover tips and best practices for them in this post. We’ll also dive into more in-depth features for those of you who want to level up and aim to perfect the craft with advanced concepts and considerations when using web fonts. In the end, you’ll hopefully feel equipped not only to put web fonts to use but to get the most out of them.

Here we go!

Font Formats

When you purchase web fonts licensing, you receive a package of font files that typically include at least some of the following formats:

  • Embedded OpenType (EOT): @font-face to include fonts in CSS.

    Here’s the deepest level of support, including all of the font file formats we’ve discussed so far:

    @font-face { font-family: FontName; src: url('path/filename.eot'); src: url('path/filename.eot?#iefix') format('embedded-opentype'), url('path/filename.woff2') format('woff2'), url('path/filename.woff') format('woff'), url('path/filename.ttf') format('truetype');
    }

    We can trim things down quite a bit if we’re only aiming to support modern browsers:

    @font-face { font-family: FontName; src: url('path/filename.woff2') format('woff2'), url('path/filename.woff') format('woff');
    }

    Once the font has been declared and defined, we can put it to use on our elements. For example:

    body { font-family: 'FontName', Helvetica, Arial, sans-serif;
    }

    Hosting Web Fonts

    One of the most flexible ways to load web fonts is to self-host them. That means that you host the files on your own server and your fonts will always be available when a visitor comes to your website without a third-party dependency. Neither tracking codes nor JavaScript is generally required to load self-hosted font files. Many small type foundries offer fonts as a direct download so they can be self-hosted and at Grilli Type, we are convinced it’s the best way to serve fonts.

    While some type foundries offer self-hosting (both with and without cumbersome restrictions and requirements), others only offer hosted solutions, meaning they host the files on your behalf. Some of the well-known ones include Hoefler & Co., Font Bureau, and Typotheque. Font Bureau and Typotheque offer their fonts in both ways at different price points.

    Make sure you know how a type foundry’s web fonts are offered before you buy licensing, because the difference in hosting and the terms of use can affect how they are implemented. Get what makes the most sense for you and fits your needs, and make sure you’re using them legally and according to the foundry’s licensing agreement.

    Advanced Typographic Features

    Let’s take a look at some of the more advanced features of web fonts.

    Spacing and Kerning

    There are two settings inside font files that define the space between characters:

    1. letter-spacing: This is defined as side bearings on the left and right side of each character
    2. font-kerning: This refers to specific adjustments between two characters

    Spacing cannot be turned off at all, because otherwise the text rendering engine (your browser) wouldn’t know what to do with these letters. Kerning, on the other hand, is turned off by default in browsers and has to be turned on by you in your CSS.

    Comparing type with kerning enabled and disabled.

    It’s easier to control kerning than you might think! Here’s how to activate it across all browsers that support it:

    p { font-feature-settings: "kern" 1; font-kerning: normal;
    }

    If you don’t use a something like Autoprefixer to help manage browser support in CSS, then you’ll want to manually write out the browser vendor prefixes for this setting to extend browser support to older versions:

    /* All vendor prefixes for `font-feature-settings` */
    p { -moz-font-feature-settings: "kern" 1; -ms-font-feature-settings: "kern" 1; -o-font-feature-settings: "kern" 1; -webkit-font-feature-settings: "kern" 1; font-feature-settings: "kern" 1; font-kerning: normal;
    }

    Advanced OpenType Features

    We just discussed how to use the font-feature-settings attribute to control kerning, but it can also be used to control other available OpenType feature in your web fonts. The number of supported features has been growing over time and the CSS-Tricks almanac is a good place to reference what is possible with OpenType.

    OpenType features are really exciting because they open up a bunch of possibilities for controlling fonts without having to serve multiple files to get the same effect. At the same time, it’s worth noting that the features an OpenType font file supports is up to the font designer and that not all fonts support the same features.

    To illustrate how advanced OpenType features can be chained together, the following code would turn on the numeric characters of an OpenType-enabled font that supports both old-style numerals (onum) and proportional numerals (pnum), plus enable kerning and activate a specific stylistic set included in the font:

    .my-element { font-feature-settings: "onum" 1, "pnum" 1, "kern" 1, "ss01" 1;
    }
    Type with and without the activated OpenType features in the code example.

    The font-feature-settings attribute can be used to activate stylistic alternates, discretionary ligatures, different types of figures available in a font, small caps, and other handy things. Typofonderie has a nice overview of these advanced features, including examples.

    Because font-feature-settings is used to set many OpenType features at once, it’s not possible to define a single setting differently as the other choices will not be inherited. All of the features would need to be defined again to change the settings for child elements.

    Letting Spacing and Word Spacing

    CSS has long supported the letter-spacing and word-spacing attributes. When used correctly, both provide a fair amount of control over two very important aspects of how your type will look.

    As with all things typography, you’ll want to learn how to evaluate different options both functionally and visually and make decisions based on your impression. Different contexts may call for different spacing needs.

    At smaller sizes, most typefaces will benefit from a little extra spacing between characters and words. In larger contexts, like headings, typefaces may benefit from more narrow spacing. In either case, the right decisions require attention and your best judgment based on the outcomes.

    I’ve found that letter-spacing and word-spacing both work best using em units for the values. That allows the spacing to adjust fluidly based on the font size of the element they are applied to. The following example will give your content a little more room to breathe at smaller font sizes:

    p { font-size: 12px; letter-spacing: 0.015em; word-spacing: 0.001em;
    }
    Comparing the difference with letter and word spacing turned on and off.

    Font Rendering

    Using type on screens brings up important questions about how they are rendered. Fonts are usually designed on about a 1000 units tall grid—or even larger—but then are displayed at something like a 16px font size. In an interplay between device, screen, and software, this reduction in resolution and fidelity requires some smarts to make small type legible and good-looking. Again, be observant, test in many browsers, and use your best judgment to put the best methods to use to increase legibility.

    Hinting

    Every operating system treats fonts differently from one another. In MacOS, the smarts are in the operating system (and thus can evolve over time), while the fonts themselves can be dumb. Historically, on Windows, the smarts were supposed to be included in the font software, and the system was supposed to use those smarts to decide how a font should be rendered at different sizes.

    Those smarts are called hinting. Hinting information embedded in the font files can tell a computer that the two stems of an “H” character are supposed to have the same line width, or that the space above and below the crossbar should stay about equal at smaller sizes.

    Hinting is a very complex and complicated topic, but the important takeaway is that the same font at the same size might render differently, even on the same computer depending on many factors, including the screen, the browser, and even the font and background color.

    Microsoft provides a guide on the topic of hinting. Even though it was initially released in 1997, it’s still a good read because it so thoroughly explores the topic.

    Font Smoothing

    While hinting information included in the font files is mostly being ignored on MacOS, specific browsers offer some additional control over font rendering.

    p { -webkit-font-smoothing: antialiased; /* Chrome, Safari */ -moz-osx-font-smoothing: grayscale; /* Firefox */
    }

    Using these CSS properties leads to sharper, thinner text rendering on MacOS and iOS. But beware: this can also lead to rendering problems, especially if you’re already using a thin font or font weight.

    Both antialiased and grayscale are mainly useful to balance the rendering of fonts when using light text on dark backgrounds, as they would otherwise get rendered quite a bit bolder.

    The font-smoothing property and its values are not on the path to become a standard CSS feature, so use it with caution and perhaps only in contexts where you know you need to target a specific browser and context.

    Caution: OptimizeLegibility

    We often come across this attribute when troubleshooting font usage on Grilli Type customer websites:

    p { text-rendering: optimizeLegibility;
    }

    Among other things, it activates kerning. That was very useful at some point, but is not needed anymore (as shown above). In addition to kerning, it also activates all kinds of ligatures, including extravagant ones that may be present in the font files.

    Although there are some use cases for this, do not use this feature if you don’t know exactly what you’re doing with it. Chance are you don’t need it in the first place.

    Web Font Resources

    If you’re ready to dive deeper into web fonts, here are a handful of recommended resources you can use to learn more:

    • Clagnut’s OpenType CSS Sandbox by Richard Rutter: A great place to test out OpenType features and easily put together your required CSS code.
    • Webfont Handbook by Bram Stein: This is the most in-depth e-book you can possibly read on web fonts, font rendering, and font performance.
    • Copy Paste Character: This is a great website that allows you to access pretty much any special character you might ever use.
    • Using @font-face by CSS-Tricks: This article includes snippets for declaring web fonts based on varying browser support.

    Advanced Web Font Considerations

    For those who are ready to level up to more advanced techniques, here are even more considerations to take into account:

    Uploading Licensed Fonts to Github

    If you commit a project to a public repo and use font files that you have licensed, please make sure that either the fonts or the directory that contains them is included in your .gitignore file so that they do not get uploaded. This will prevent others from taking and using your font files, and it can prevent you from breaking any terms of use for licensed fonts that usually have usage and sharing restrictions.

    .DS_Store path/to/web/fonts/folder/*

    Font Loading Tactics

    Loading web fonts can be as easy as simply using @font-face but that doesn’t necessarily offer the best possible performance. For example, it opens up the possibility of a Flash Of Unstyled Text (FOUT) which might be considered poor “A Comprehensive Guide to Font Loading Strategies” covers that and methods to improve the loading experience that will make you and your users very happy.

    Base64-Encoded Font Files

    In some rare instances, encoding your fonts as base64 inside your CSS will be a good idea but, generally, it is not—and, not to mention, you might break your font’s licensing agreement in the process. Be sure to proceed with a lot of caution and read up on your font’s terms of use when considering base64.

    CSS Text Decoration

    The W3C is working on a draft for new controls for text decoration, mainly dealing with how to make underlining text better and easier in CSS. This is not yet usable across all browsers, but have a look!

    Variable Fonts

    In 2017, the OpenType fonts specification 1.8.2 was released, allowing for what is called Variable Fonts. This new version of OpenType will allow for the inclusion of multiple font styles into a single font file, reducing server requests and web font file sizes. Depending on the type designer’s choices, it may also allow for the use of arbitrary weights in between existing weights and widths of fonts, among other things. Axis Praxis is a good website to play around with some existing test fonts – you will need a recent version of Safari or Chrome to do so, though.

    Wrapping Up

    We covered a lot in this article! Hopefully now you have a good understanding of the different font files out there, how to work with them, and all the amazing and powerful ways fonts can be styled using both tried and true methods and cutting-edge features.


    Understanding Web Fonts and Getting the Most Out of Them is a post from CSS-Tricks

My Talk Writing Process

Some people have a talk preparation process that is super organized and runs like a well-oiled machine. Mine, on the other hand, is a bit messy, but it works for me. Even when a talk looks polished and put together on stage, it doesn’t mean the process to get it there was that way too.

Me on stage at An Event Apart.

When putting together a new talk recently, I noticed there was most definitely a pattern to how my talks take shape. Here’s how the talk-making process goes for me:

The Research Phase

True to the nature of research, all my talks start by collecting articles, books, videos, and other things that relate to the topic of the talk. At this point in the talk development process, I usually only have a general topic idea instead of a fully fleshed out point-of-view or main message. That means I end up collecting things that might only be tangentially related to the topic and going down some strange topical rabbit holes.

I’ll save all these as a collection of bookmarks but usually also in a Google Doc with notes or quotes from the piece that seem most relevant. That makes it easier to keep a high-level view of what I’ve collected, and even discover interesting threads that connect some of the seemingly unrelated sources.

This initial phase is intentionally fuzzy on focus. Only a small percentage of the research I collect actually makes it to the end talk content. Sometimes the things that don’t make it spark ideas for other talks, or just gets filed away in my brain for future (hopefully interesting) things.

Outlining: The Giant Mess Phase

There’s probably a smarter sounding name for this phase, but for every talk I’ve done, there’s always a point where I step back and think, “Holy crap this is all a giant mess! What am I even doing with all this!?” So, that’s what I’ll call this phase. This is the phase where I make a general outline for the talk (again in a Google Doc or Word file) and start fitting my thoughts, examples or demos, and relevant research into it.

I outline the major points I think the talk should make and try to fit them into some sort of narrative order. These tend to change and morph a bit as the talk takes shape, but that’s OK because I’m still in the giant mess phase.

At the top of my document I have a three-part block that helps keep me focused:

What is the main question this talk answers (or the main problem it addresses)?

What is the main message of this talk?

Three points that support the main message:

(I started doing this on advice from Bill Smartt, and it’s been a huge help ever since.)

A talk outline for a 30 min talk complete with comments to myself.

The rest of the document addresses the body of the talk with each main point as a headline and some notes underneath it. Personally, I don’t write out talks word-for-word and memorize them. I do write out an introduction and conclusion to make sure I’m setting up the topic and summarizing it well, but the rest of the notes are bulleted lists of points to make and references supporting examples, demos, or references. I leave space at the bottom of the document for random thoughts and notes as well as probably a few too many comments to myself on possible changes to make or different directions to take. Points that don’t fit into the main narrative get moved down to this section too.

Once I feel like I have a cohesive outline, or at least one that isn’t a total mess, I move on to making some visuals.

The Editing Phase

A recent talk with all the edited-out slides shown ghosted out. Those slides never made it to the final talk.

This is the point where I start making slides and such based on the outline. Some people leave slides to the very last thing, but I leave them more to the almost last thing and do some of my thinking and organizing while I build up the slide deck.

I’ll make slides for each point in the outline, take screen recordings of demos or examples, and start piecing things together in order. I tend to think of my talks in sections at this point and, as I create the slides for each section, I’ll try talking through them out loud to see how they flow. (It’s amazing how different things sound when you say them out loud!)

There is a lot of rearranging and cutting out during this phase to work towards something that feels cohesive. I keep working on adding, deleting, and rearranging slides until I’ve got visuals for the full narrative of my outline. Sometimes things fall into place quickly, but for most talks this part can take a while.

At this point I almost always have far too much content. I’ll run through what I have for the talk in 10 to 15 minute chunks, editing down and solidifying points until I’ve got something that fits neatly into the required time length. Most times this means a 30 minutes and 45-60 minute version of the talk depending on the format of the event where it’s being given.

The same talk without the slides that have been edited out.

Rehearsing: The Talking to Myself Phase

Rehearsing is so important but it can also be very awkward. It seems like everyone has a different strategy for rehearsing talks, which totally makes sense. I have a really hard time rehearsing talks in their entirety when I’m standing in my office talking to the wall or to the dog, so I tend to rehearse in 15 or 30 minute chunks; practicing the first half then taking a break to do some other things and coming back to run through the second half. That way I know I have a handle on all the material, but haven’t driven myself (or the dog) up a wall with all that talking to no one in particular.

Ah, that familiar presenter notes view. I like a giant notes window even though I rarely actually read them while I’m on stage. They’re a “just in case” kind of thing.

As often as possible I’ll try to give a new talk to a few friends or at a meetup before doing it on stage for the first time. Having a real live human audience can really help show which points are strong and which might need a bit more work to get across well. I also always run through the “final” talk from start-to-finish at least once in the 24 hours before I’ll be on stage to make sure all the content is fresh in my mind.

A Talk is Never Really Done

Seriously. They really never are. The funny thing about talks is that when you give them more than once, they’re rarely exactly the same. (Yes, it is totally fine to do the same talk more than once.) There is always something to improve, something to add, or new points or examples to add to the narrative.

I usually make notes for myself on what worked or what didn’t right after getting off stage. That’s a good time to recall which parts of the talk felt like they could use some work, but it’s not such a good time to actually make any edits. I’ll go back to those notes a few days later (having some space here is really helpful) and make adjustments as needed. Also, if I come across other relevant examples or research at any point in time, I’ll try to add them into the talk for the next time around.

You Do You

If there’s one thing I’ve learned working on talks and talking to other speakers about their process, it’s that no two people work the same way. Everyone has their own way of putting together talks that they’ve customized for their own habits and preferences. If your talk development process looks nothing like mine, that’s totally fine. And if you haven’t found a process that works for you yet, keep experimenting with different techniques. You’ll find one that works for you!

For more on how to get a talk together, check out these other articles too:

  • How to Write a Talk
  • My Process: Writing a Talk
  • Three things you don’t need to become a speaker
  • How to write a successful talk proposal

My Talk Writing Process is a post from CSS-Tricks

CSS Basics: Fallback Font Stacks for More Robust Web Typography

In CSS, you might see a ruleset like this:

html { font-family: Lato, "Lucida Grande", Tahoma, Sans-Serif;
}

What the heck, right? Why don’t I just tell it what font I want to use and that’s that? The whole idea here is fallbacks. The browser will try to use the font you specified first (Lato, in this case), but if it doesn’t have that font available, it will keep going down that list. So to be really verbose here, what that rule is saying is:

  1. I’d like to use the Lato font here, please.
  2. If you don’t have that, try “Lucida Grande” next.
  3. If you don’t have that, try Tahoma.
  4. All else fails, use whatever you’ve got for the generic keyword Sans-Serif

So in what situation would a browser not have the font you’re asking for? That’s pretty common. There are only a handful of fonts that are considered “web safe”—meaning that it’s likely most computers visiting your site have that font installed and so the browser can use it. Think: Arial, Times New Roman, Courier, Georgia, Verdana, and a handful of others.

But most websites, these days, use custom web fonts. They load up a font as a resource (just as a website loads CSS itself as a resource, or an image, or JavaScript), then that font is available to use. The widely popular Google Fonts makes that pretty clear:

Load this font first, then you can use it in CSS.

Even when you load a font in this way, it’s still possible that the font doesn’t load. While Google is a generally very reliable host, you don’t control their servers; they do. Even more commonly, poor network connections may prevent a font from loading. In any font loading failure scenario, that’s another situation where a fallback font stack comes in handy.

Say I’m using the custom font Merriweather, and I set up my font stack like this:

html { font-family: Merriweather, Impact, Serif;
}

If Merriweather fails to load (or does load, but loads in such a way that it pops into place after it does—also known as FOUT), we’d see something like this:

A fallback font, in this case Impact, is seen. It’s incredibly awkward and doesn’t match the desired look at all.

Better to have your font fall back to something close to your top choice than to something totally unrelated! There is a fantastic tool by Monica Dinculescu call Font style matcher where you can play with fallbacks (that’s how I made that GIF above).

In the example above, we can see that Georgia is a much nicer fallback font than Impact is! The example is a little bit more fancy than just changing the font though. A couple of other settings were changed to make them match as closely as they are. To take advantage of that, you’re in font loading territory, which gets a bit complex. Your best bet there is consulting Zach Leatherman’s A Comprehensive Guide to Font Loading. In any case, picking a nice fallback font alone is worth doing.

Individual Characters

An interesting note about fallback fonts is that it’s not all-or-nothing. Individual characters in a font can fall down the stack if the specified font doesn’t have that character available.

As an extreme example, I’ll load the custom font Source Code Pro from Google Fonts but I’ll force it to only contain a handful of letters.

You can see in the first sentence how the fallback fonts took over and the end result wasn’t disastrous (like the second sentence) even though the custom font didn’t have some of the characters available. This will be more likely to happen with things like uncommon ASCII characters or even accented characters like ü, ā, or ñ.

As some side fun, here’s using that character fallback ability of CSS to do something unique:

See the Pen Ransom Note With Google Font Subsets by Heydon (@heydon) on CodePen.

More Reading

  • Font Stack Snippets: Some common font stacks
  • CSS Font Stack: A collection of web safe CSS font stacks
  • System Font Stack: A snippet that uses the computer’s default system font

CSS Basics: Fallback Font Stacks for More Robust Web Typography is a post from CSS-Tricks

CSS Basics: Styling Links Like a Boss

The web was founded on links. The idea that we can click/tap a link and navigate from one web page to another is how surfin’ the web become a household phrase.

Links in HTML even look different from regular text without any CSS styling at all.

See the Pen Default Link by CSS-Tricks (@css-tricks) on CodePen.

They are blue (purple if visited). They are underlined. That’s a link in it’s purest form.

But what if we want to change things up a bit? Perhaps blue doesn’t work with your website’s design. Maybe you have an aversion to underlines. Whatever the reason, CSS lets us style links just we can any other element. All we need to do is target the <a> element in our stylesheet.

Want to use a different font, change the color, remove the underline and make it all uppercase? Sure, why not?

a { color: red; text-decoration: none; text-transform: uppercase;
}

See the Pen Link With Some Style by Geoff Graham (@geoffgraham) on CodePen.

Now we’re cooking with gas! But why stop there? Let’s look at a few other ways we can style links to complete the experience.

Style Each Link State

Links have different states, meaning they adapt when we interact with them on a webpage. There are three additional states of a link that are worth considering anytime we change the default style of links:

  • Hover (:hover): When the mouse cursor is place on top of the link without a click
  • Visited (:visited): The appearance of a link that the user has clicked on the page before when the mouse cursor is not on top of it
  • Active (:active): When the link is in the process of being clicked. It might be super quick, but this is when the mouse button has been depressed and before the click is over.

Here is the same link we have been looking at. First, try hovering your mouse on top of it without clicking and notice that it becomes underlined. Then, click on the link, but leave your mouse button clicked down for a little bit to see how the active style changes the color of the link to black. Finally, let up on the mouse button and the link should turn purple before it’s technically been visited.

See the Pen Link With Styled States by Geoff Graham (@geoffgraham) on CodePen.

Links seem like a simple concept, but boy do they have a lot going on—and CSS gives us some incredible power to customize the experience!

Links as Buttons

While there is some debate about it, we can use CSS to make a text link look like a button.

Like other HTML elements, CSS can add background colors and padding to links that allow us to create the appearance of a button. Here’s our link using those techniques:

a { background-color: red; color: white; padding: 1em 1.5em; text-decoration: none; text-transform: uppercase;
}

See the Pen Link as a Button by CSS-Tricks (@css-tricks) on CodePen.

Great! Now, let’s use the state-altering powers we learned in the last section to make our faux-button more interactive. We’ll make the button dark gray on hover, black on active, and light gray on visit:

a { background-color: red; color: white; padding: 1em 1.5em; text-decoration: none; text-transform: uppercase;
} a:hover { background-color: #555;
} a:active { background-color: black;
} a:visited { background-color: #ccc;
}

See the Pen Link as a Button With Styled States by Geoff Graham (@geoffgraham) on CodePen.

Styling a link as a button and taking advantage of the states allows us to make some pretty cool effects. For example, let’s create a button with some depth that appears to get pressed when it’s active and pop back up when the click is done.

See the Pen Link as a 3D Button by Geoff Graham (@geoffgraham) on CodePen.

Oh, and Cursors!

We’ve gone into pretty great depth on style links, but there is one more component to them that we cannot ignore: the cursor.

The cursor indicates the position of the mouse on the screen. We’re pretty used to the standard black arrow:

The standard mouse cursor arrow

We can change the arrow to a hand pointer on it’s hover (:hover) state so that it’s easier to see that the link indicates it is an interactive element:

Using cursor:
pointer;
provides an interactive cue.
a:hover { cursor: pointer;
}

See the Pen Link as a 3D Button With Pointer by Geoff Graham (@geoffgraham) on CodePen.

Whew, that’s much nicer! Now, we have a pretty fancy link that looks like a button with proper interactive cues.

Leveling Up

We’ve covered quite a bit of ground here, but it merely scratches the surface of how we can control the style of links. If you’re ready to level up, then here are a few resources you can jump into from here:

  • Mailto Links – A good reference for linking up email addresses instead of webpages.
  • The Current State of Telephone Links – Did you know you can link a phone number? Well, here’s how.
  • Cursor – The CSS-Tricks reference guide for customizing the cursor.
  • When to Use the Button Element – If you’re wondering about the difference between a link button and a traditional form button, then this is a good overview with suggestions for which is better for specific contexts.
  • Button Maker – A free resource for generating the CSS for link buttons.

CSS Basics: Styling Links Like a Boss is a post from CSS-Tricks

CSS Basics: Using Multiple Backgrounds

With CSS, you can control the background of elements. You can set a background-color to fill it with a solid color, a background-image to fill it with (you guessed it) an image, or even both:

body { background-color: red; background-image: url(pattern.png);
}

Here’s an example where I’m using an SVG image file as the background, embedded right in the CSS as a data URL.

See the Pen background color and image together by Chris Coyier (@chriscoyier) on CodePen.

That’s just a single image there, repeated, but we can actually set multiple background images if we want. We do that by separating the values with commas.

body { background-image: url(image-one.jpg), url(image-two.jpg);
}

If we leave it like that, image-one.jpg will repeat and entirely cover image-two.jpg. But we can control them individually as well, with other background properties.

body { background-image: url(image-one.jpg), url(image-two.jpg); background-position: top right, /* this positions the first image */ bottom left; /* this positions the second image */ background-repeat: no-repeat; /* this applies to both images */
}

See how background-position also has comma-separated values? Those will apply individually to each image respectively. And then how background-repeat has only one value? We could have done two values in the same way, but by using just one value, it applies to both.

Here’s an example using four separate images, one in each corner, offset by a smidge:

See the Pen Example of multiple backgrounds by Chris Coyier (@chriscoyier) on CodePen.

It’s too bad you can’t rotate or flip background images or else we could have used just one. We can rotate and flip entire elements (or psuedo elements) though, so in cases like that, we can get away with using a single image!

See the Pen Flipping Image So You Can Use Just One by Chris Coyier (@chriscoyier) on CodePen.

Just a few other things to be aware of here:

  1. The stacking order of multiple background is “first is on top.”
  2. Gradients are applied through background-image, so they can be used as part of all this. For example, you could set a transparent gradient over a raster image.

See the Pen Tinted Image w/ Multiple Backgrounds by Chris Coyier (@chriscoyier) on CodePen.


CSS Basics: Using Multiple Backgrounds is a post from CSS-Tricks

CSS Basics: The Second “S” in CSS

CSS is an abbreviation for Cascading Style Sheets.

While most of the discussion about CSS on the web (or even here on CSS-Tricks) is centered around writing styles and how the cascade affects them, what we don’t talk a whole lot about is the sheet part of the language. So let’s give that lonely second “S” a little bit of the spotlight and understand what we mean when we say CSS is a style sheet.

The Sheet Contains the Styles

The cascade describes how styles interact with one another. The styles make up the actual code. Then there’s the sheet that contains that code. Like a sheet of paper that we write on, the “sheet” of CSS is the digital file where styles are coded.

If we were to illustrate this, the relationship between the three sort of forms a cascade:

The sheet holds the styles.

There can be multiple sheets all continuing multiple styles all associated with one HTML document. The combination of those and the processes of figuring out what styles take precedence to style what elements is called the cascade (That first “C” in CSS).

The Sheet is a Digital File

The sheet is such a special thing that it’s been given its own file extension: .css. You have the power to create these files on your own. Creating a CSS file can be done in any text editor. They are literally text files. Not “rich text” documents or Word documents, but plain ol’ text.

If you’re on Mac, then you can fire up TextEdit to start writing CSS. Just make sure it’s in “Plain Text” mode.

If you’re on Windows, the default Notepad app is the equivalent. Heck, you can type styles in just about any plain text editor to write CSS, even if that’s not what it says it was designed to do.

Whatever tool you use, the key is to save your document as a .css file. This can usually be done by simply add that to your file name when saving. Here’s how that looks in TextEdit:

Seriously, the choice of which text editor to use for writing CSS is totally up to you. There are many, many to choose from, but here are a few popular ones:

  • Sublime Text
  • Atom
  • VIM
  • PhpStorm
  • Coda
  • Dreamweaver

You might reach for one of those because they’ll do handy things for you like syntax highlight the code (colorize different parts to help it be easier to understand what is what).

Hey look I made some files completely from scratch with my text editor:

Those files are 100% valid in any web browser, new or old. We’ve quite literally just made a website.

The Sheet is Linked Up to the HTML

We do need to connect the HTML and CSS though. As in make sure the styles we wrote in our sheet get loaded onto the web page.

A webpage without CSS is pretty barebones:

See the Pen Style-less Webpage by Geoff Graham (@geoffgraham) on CodePen.

Once we link up the CSS file, voila!

See the Pen Webpage With Styles by Geoff Graham (@geoffgraham) on CodePen.

How did that happen? if you look at the top of any webpage, there’s going to be a <head> tag that contains information about the HTML document:

<!DOCTYPE html>
<html> <head> <!-- a bunch of other stuff --> </head> <body> <!-- the page content --> </body> </html>

Even though the code inside the <head> might look odd, there is typically one line (or more, if we’re using multiple stylesheets) that references the sheet. It looks something like this:

<head> <link rel="stylesheet" type="text/css" href="styles.css" />
</head>

This line tells the web browser as it reads this HTML file:

  1. I’d like to link up a style sheet
  2. Here’s where it is located

You can name the sheet whatever you want:

  • styles.css
  • global.css
  • seriously-whatever-you-want.css

The important thing is to give the correct location of the CSS file, whether that’s on your web server, a The Sheet is Not Required for HTML
You saw the example of a barebones web page above. No web page is required to use a stylesheet.
Also, we can technically write CSS directly in the HTML using the HTML style attribute. This is called inline styling and it goes a little something like this if you imagine you’re looking at the code of an HTML file:
<h1 style=”font-size: 24px; line-height: 36px; color: #333333″>A Headline</h1>
<p style=”font-size: 16px; line-height: 24px; color: #000000;”>Some paragraph content.</p>
<!– and so on –>
While that’s possible, there are three serious strikes against writing styles this way: If you decide to use a stylesheet later, it is extremely difficult to override inline styles with the styles in the HTML. Inline styles take priority over styles in a sheet.
Maintaining all of those styles is tough if you need to make a “quick” change and it makes the HTML hard to read.
There’s something weird about saying we’re writing CSS inline when there really is no cascade or sheet. All we’re really writing are styles. There is a second way to write CSS in the HTML and that’s directly in the <head> in a <style> block:
<head> <style> h1 { color: #333; font-size: 24px; line-height: 36px; } p { color: #000; font-size: 16px; line-height: 24px; } </style>
</head>
That does indeed make the HTML easier to read, already making it better than inline styling. Still, it’s hard to manage all styles this way because it has to be managed on each and every webpage of a site, meaning one “quick” change might have to be done several times, depending on how many pages we’re dealing with.
An external sheet that can be called once in the <head> is usually your best bet.
The Sheet is Important
I hope that you’re starting to see the importance of the sheet by this point. It’s a core part of writing CSS. Without it, styles would be difficult to manage, HTML would get cluttered, and the cascade would be nonexistent in at least one case.
The sheet is the core component of CSS. Sure, it often appears to play second fiddle to the first “S” but perhaps that’s because we all have an quiet understanding of its importance.
Leveling Up
Now that you’re equipped with information about stylesheets, here are more resources you jump into to get a deeper understanding for how CSS behaves: Specifics on Specificity – The cascade is a confusing concept and this article breaks down the concept of specificity, which is a method for how to manage it.

  • The latest ways to deal with the cascade, inheritance and specificity – That’s a lot of words, but the this article provides pro tips on how to manage the cascade, including some ideas that may be possible in the future.
  • Override Inline Styles with CSS – This is an oldie, but goodie. While the technique is probably not best practice today, it’s a good illustration of how to override those inline styles we mentioned earlier.
  • When Using !important is The Right Choice – This article is a perfect call-and-response to the previous article about why that method may not be best practice.

  • CSS Basics: The Second “S” in CSS is a post from CSS-Tricks

    Direction Aware Hover Effects

    This is a particular design trick that never fails to catch people’s eye! I don’t know the exact history of who-thought-of-what first and all that, but I know I have seen a number of implementations of it over the years. I figured I’d round a few of them up here.

    Noel Delagado

    See the Pen Direction-aware 3D hover effect (Concept) by Noel Delgado (@noeldelgado) on CodePen.

    The detection here is done by tracking the mouse position on mouseover and mouseout and calculating which side was crossed. It’s a small amount of clever JavaScript, the meat of which is figuring out that direction:

    var getDirection = function (ev, obj) { var w = obj.offsetWidth, h = obj.offsetHeight, x = (ev.pageX - obj.offsetLeft - (w / 2) * (w > h ? (h / w) : 1)), y = (ev.pageY - obj.offsetTop - (h / 2) * (h > w ? (w / h) : 1)), d = Math.round( Math.atan2(y, x) / 1.57079633 + 5 ) % 4; return d;
    };

    Then class names are applied depending on that direction to trigger the directional CSS animations.

    Fabrice Weinberg

    See the Pen Direction aware hover pure CSS by Fabrice Weinberg (@FWeinb) on CodePen.

    Fabrice uses just pure CSS here. They don’t detect the outgoing direction, but they do detect the incoming direction by way of four hidden hoverable boxes, each rotated to cover a triangle. Like this:

    Codrops

    Demo

    In an article by Mary Lou on Codrops from 2012, Direction-Aware Hover Effect with CSS3 and jQuery, the detection is also done in JavaScript. Here’s that part of the plugin:

    _getDir: function (coordinates) { // the width and height of the current div var w = this.$el.width(), h = this.$el.height(), // calculate the x and y to get an angle to the center of the div from that x and y. // gets the x value relative to the center of the DIV and "normalize" it x = (coordinates.x - this.$el.offset().left - (w / 2)) * (w > h ? (h / w) : 1), y = (coordinates.y - this.$el.offset().top - (h / 2)) * (h > w ? (w / h) : 1), // the angle and the direction from where the mouse came in/went out clockwise (TRBL=0123); // first calculate the angle of the point, // add 180 deg to get rid of the negative values // divide by 90 to get the quadrant // add 3 and do a modulo by 4 to shift the quadrants to a proper clockwise TRBL (top/right/bottom/left) **/ direction = Math.round((((Math.atan2(y, x) * (180 / Math.PI)) + 180) / 90) + 3) % 4; return direction;
    },

    It’s technically CSS doing the animation though, as inline styles are applied as needed to the elements.

    John Stewart

    See the Pen Direction Aware Hover Goodness by John Stewart (@johnstew) on CodePen.

    John leaned on Greensock to do all the detection and animation work here. Like all the examples, it has its own homegrown geometric math to calculate the direction in which the elements were hovered.

    // Detect Closest Edge
    function closestEdge(x,y,w,h) { var topEdgeDist = distMetric(x,y,w/2,0); var bottomEdgeDist = distMetric(x,y,w/2,h); var leftEdgeDist = distMetric(x,y,0,h/2); var rightEdgeDist = distMetric(x,y,w,h/2); var min = Math.min(topEdgeDist,bottomEdgeDist,leftEdgeDist,rightEdgeDist); switch (min) { case leftEdgeDist: return "left"; case rightEdgeDist: return "right"; case topEdgeDist: return "top"; case bottomEdgeDist: return "bottom"; }
    } // Distance Formula
    function distMetric(x,y,x2,y2) { var xDiff = x - x2; var yDiff = y - y2; return (xDiff * xDiff) + (yDiff * yDiff);
    }

    Gabrielle Wee

    See the Pen CSS-Only Direction-Aware Cube Links by Gabrielle Wee ✨ (@gabriellewee) on CodePen.

    Gabrielle gets it done entirely in CSS by positioning four hoverable child elements which trigger the animation on a sibling element (the cube) depending on which one was hovered. There is some tricky stuff here involving clip-path and transforms that I admit I don’t fully understand. The hoverable areas don’t appear to be triangular like you might expect, but rectangles covering half the area. It seems like they would overlap ineffectively, but they don’t seem to. I think it might be that they hang off the edges slightly giving a hover area that allows each edge full edge coverage.

    Elmer Balbin

    See the Pen Direction Aware Tiles using clip-path Pure CSS by Elmer Balbin (@elmzarnsi) on CodePen.

    Elmer is also using clip-path here, but the four hoverable elements are clipped into triangles. You can see how each of them has a point at 50% 50%, the center of the square, and has two other corner points.

    clip-path: polygon(0 0, 100% 0, 50% 50%)
    clip-path: polygon(100% 0, 100% 100%, 50% 50%);
    clip-path: polygon(0 100%, 50% 50%, 100% 100%);
    clip-path: polygon(0 0, 50% 50%, 0 100%);

    Nigel O Toole

    Demo

    Raw JavaScript powers Nigel’s demo here, which is all modernized to work with npm and modules and all that. It’s familiar calculations though:

    const _getDirection = function (e, item) { // Width and height of current item let w = item.offsetWidth; let h = item.offsetHeight; let position = _getPosition(item); // Calculate the x/y value of the pointer entering/exiting, relative to the center of the item. let x = (e.pageX - position.x - (w / 2) * (w > h ? (h / w) : 1)); let y = (e.pageY - position.y - (h / 2) * (h > w ? (w / h) : 1)); // Calculate the angle the pointer entered/exited and convert to clockwise format (top/right/bottom/left = 0/1/2/3). See https://stackoverflow.com/a/3647634 for a full explanation. let d = Math.round(Math.atan2(y, x) / 1.57079633 + 5) % 4; // console.table([x, y, w, h, e.pageX, e.pageY, item.offsetLeft, item.offsetTop, position.x, position.y]); return d;
    };

    The JavaScript ultimately applies classes, which are animated in CSS based on some fancy Sass-generated animations.

    Giana

    A CSS-only take that handles the outgoing direction nicely!

    See the Pen CSS-only directionally aware hover by Giana (@giana) on CodePen.


    Seen any others out there? Ever used this on something you’ve built?


    Direction Aware Hover Effects is a post from CSS-Tricks

    Offline *Only* Viewing

    It made the rounds a while back that Chris Bolin built a page of his personal website that could only be viewed while you are offline.

    This page itself is an experiment in that vein: What if certain content required us to disconnect? What if readers had access to that glorious focus that makes devouring a novel for hours at a time so satisfying? What if creators could pair that with the power of modern devices? Our phones and laptops are amazing platforms for inventive content—if only we could harness our own attention.

    Now Bolin has a whole magazine around this same concept called The Disconnect!

    The Disconnect is an offline-only, digital magazine of commentary, fiction, and poetry. Each issue forces you to disconnect from the internet, giving you a break from constant distractions and relentless advertisements.

    I believe it’s some Service Worker trickery to serve different files depending on the state of the network. Usually, Service Workers are meant to serve cached files when the network is off or slow such as to make the website continue to work. This flips that logic on its head, preventing files from being served until the network is off.


    Offline *Only* Viewing is a post from CSS-Tricks