Tag: Future

Leading-Trim: The Future of Digital Typesetting

leading-trim is a suggested new CSS property that lets us remove the extra spacing in every font so that we can more predictably style text. Ethan Wang has written about it — including how Microsoft has advocated for it — and that it’s now part of the Inline Layout Module Level 3 spec.

You’d use it like this:

h1 {   leading-trim: both;  text-edge: cap alphabetic; }

This is telling the browser to look at the font file, dig into the OpenType metrics, and effectively do what Ethan demonstrates in this gif:

Why do we want to do this? Well, it would let us space text inside a button properly without any strange hacks and we’d be able to set predictable spacing values between different typefaces too. I’m pretty excited about this spec and the CSS property because it gives us yet one more tool to control the use of typography on the web — like taming line height.

Direct Link to ArticlePermalink

The post Leading-Trim: The Future of Digital Typesetting appeared first on CSS-Tricks.

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


, , ,

Motion Paths – Past, Present and Future

Cassie Evans has a great intro to motion paths. That is, being able to animate an element along a path. Not just up/down/left/right, but whatever curvy/wiggly/weird path you want.

It’s an interesting subject because there are so many different technologies helping to do it over time. SMIL, JavaScript-powered animation libraries, native JavaScript APIs, and even CSS via offset-path and friends. I think offset-path is funny – it was changed to that name from motion-path as you don’t technically have to apply motion to an element you place on a path in this way.

There’s no clear winner. I’m (perhaps obviously) a fan of doing stuff like this in CSS whenever possible, but the browser support there is essentially Chrome-only. Plus seeing SVG path values in CSS always feels a smidge uncomfortable because of the unitless numbers. SMIL feels like essentially dead technology, but at least then you’re in SVG-land and the paths make good sense in that context. If browser support is vital, you have to use a library.

I do think there is untapped cool design possibility in motion paths. It’s not just for landing space ships, but can be for practical stuff like how a modal enters a page.

Direct Link to ArticlePermalink

The post Motion Paths – Past, Present and Future appeared first on CSS-Tricks.


, , , ,

The future is bright, because the future is static

I’ve been doing this web thing for money for 10 years this year and although I haven’t been around as long as some folks, I feel like I’ve seen a few cycles come and go now, so let’s say that hot new things are often cynically viewed, initially. This milestone of mine has also got me in a retrospective mood, too, and the question “What about building websites has you interested this year?“ has only encouraged that.

When I first came into the industry, I was an out-and-out designer, delivering static comps to developers until after one-too-many poor builds of my work: I decided to get into code myself. Naturally I focused purely on the front-end—specifically HTML and CSS. Yes, I got a bit into JavaScript too (once Flash became fully irrelevant), but markup and styles have always been my favorite things about web technology. I’ve never really been into back-end development, either. Sure, I can do it, but it’s certainly not my strong suit and usually this weakens my offering a touch—especially as a freelance web designer. Well, it did weaken me, until now.

JAMstack: an awful name, but awfully empowering.

I love JAMstack because it empowers people like me, who aren’t very strong with back-end stuff, and the aspect of JAMstack that I like the most—and which I think is the best part—is static site generators (SSGs). I’m talking specifically about SSGs like Eleventy and less-so Gatsby here, for reference.

The biggest reason that I like SSGs like Eleventy is that I can have a completely flexible, component-driven codebase that at build-time, compiles down to nothing but lovely, static HTML. You still get the power of JavaScript too, but instead of forcing it down the pipe, you run it at compile-time. This has enabled me to do some pretty darn complex stuff. Eleventy does all of this at lightning speed, too.

Mix Eleventy with Netlify and in some cases, Heroku, and suddenly you have a powerful development setup which results in a fast, performant website that auto-deploys. It’s perfect setup for me.

This stuff excites me so much that I made an Eleventy starter kit this year called Hylia. I did this for two reasons:

  1. I wanted to test the viability of a content-managed static-site that uses source controlled content. I chose Netlify CMS to do this
  2. I wanted to empower people without tech skills to publish a performant, accessible blog of their own, so they didn’t have to rely on centralised systems

The platform went down really well and I think part of the reason for its success is that even though it’s (optionally) content managed, powered by design tokens and fully componentized, it performs really well because all you get is HTML and CSS with a bit of progressively enhanced JavaScript.

This is the magic of SSGs, because they give us developer experience, but much more importantly, because the output is static and lightweight (unless you prevent that with lots of code), it creates a really solid basis for a good user experience, too! This isn’t just the case for small projects like Hylia, too, because SSGs can even power huge projects like the Duet Design System, for example.

Looking back at the empowerment that SSGs enable, I’ll just list some things that they have enabled me, a web designer, to do this year:

  • Self-publish a book
  • Create rapid, interactive prototypes for clients which has completely transformed the decision making process
  • Build actual, full websites for clients
  • Completely transform my design process to use HTML and CSS as a deliverables, rather than static comps
  • Build and document an incredibly comprehensive, multi-platform design system (WIP)
  • Re-platform my CSS newsletter (WIP)

These are huge things that have had a massive, positive impact on me and next year, SSGs are only going to feature more in my work as I transition into providing educational material, too.

Wrapping up

The future is bright with the JAMstack and SSGs—especially when what is delivered to the end-user is fast, progressively enhanced websites. I honestly think that they are creating a momentum wave towards a bigger focus in performance, too.

If we chuck in some serverless technology: suddenly, designers and front-end developers really are all powerful and this really excites me because suddenly, we give lots of people power to have great ideas that might not have been able to before.

The post The future is bright, because the future is static appeared first on CSS-Tricks.


, , ,

Why Progressive Web Apps Are The Future of Mobile Web

Here’s one of the best essays I’ve ever read about why progressive web apps are important, how they work, and what impact they have on a business:

PWAs are powerful, effective, fast and app-like.

It’s hard to imagine a mobile web property that could not be significantly improved via PWA implementation. They can also potentially eliminate the need for many “vanity” native apps that exist today.

My only small disagreement with this piece is their use of the term “mobile web.” I know it’s a tiny thing to get persnickety over but my hot take after reading it is this: it’s important to remember that progressive web apps are for everyone, desktop and mobile users alike. I think it’s important to reiterate that there is no mobile web. And that our goal is to be better than native.

Direct Link to ArticlePermalink

The post Why Progressive Web Apps Are The Future of Mobile Web appeared first on CSS-Tricks.


, , ,

Bridging the Gap Between CSS and JavaScript: CSS Modules, PostCSS and the Future of CSS

In the previous post in this two-part series, we explored the CSS-in-JS landscape and, we realized not only that CSS-in-JS can produce critical styles, but also that some libraries don’t even have a runtime. We saw that user experience can significantly improve by adding clever optimizations, which is why this series focuses on developer experience (the experience of authoring styles).

In this part, we’ll explore the tools for “plain ol’ CSS” by refactoring the Photo component from our existing example.

Controversy and #hotdrama

One of the most famous CSS debates is whether the language is fine just the way that it is. I think this debate stays alive because there is some truth to both sides. For example, while it’s true that CSS was initially designed to style a document rather than components of an application, it’s also true that upcoming CSS features will dramatically change this, and that many CSS mistakes stem from treating styling as an afterthought instead of taking time to learn it properly or hiring someone who’s good at it.

I don’t think that CSS tools themselves are the source of the controversy; we’ll probably always use them to some extent at the very least. But approaches like CSS-in-JS are different in that they patch up the shortcomings of CSS with client-side JavaScript. However, CSS-in-JS is not the only approach here; it is merely the newest. Remember when we used to have similar debates about preprocessors, like Sass? Sass has features, like mixins, that aren’t based on any CSS proposal (not to mention the entire indented syntax). However, Sass was born in a much different time and has reached a point where it’s no longer fair to include it in the debate because the debate itself has changed — so we started criticizing CSS-in-JS because it’s an easier target.

I think we should use tools that let us use proposed syntax today. Let’s use JavaScript Promises as an analogy. This feature isn’t supported by Internet Explorer, so many people include a polyfill for it. The point of polyfills is to enable us to pretend like the feature is supported everywhere by substituting native browser implementations with a patch. Same goes for transpiling new syntax with tools, like Babel. We can use it today because the code will be compiled to an older, well-supported syntax. This is a good approach because it allows us to use future features today while pushing JavaScript forward the way preprocessing tools, like Sass, have pushed CSS forward.

My take on the CSS controversy is that we should use tools that enable us to use future CSS today.


We’ve already talked a bit about CSS preprocessors, so it’s worth discussing them in a little more details and how they fit into the CSS-in-JS conversation. We have Sass, Less and PostCSS (among others) that can imbue our CSS code with all kinds of new features.

For our example, we’re only going to be concerned with nesting, one of the most common and powerful features of preprocessors. I suggest using PostCSS because it gives us fine-grained control over the features we’re adding, which is exactly what we need in this case. The PostCSS plugin that we’re going to use is postcss-nesting because it follows the actual proposal for native CSS nesting.

The best way to use PostCSS with our compiling tool, webpack, is to add postcss-loader after css-loader in the configuration. When adding loaders after css-loader, it’s important to account for them in the css-loader options by setting importLoaders to the number of succeeding loaders, which in this case is 1:

{   test: /\.css$  /,   use: [     'style-loader',     {       loader: 'css-loader',       options: {         importLoaders: 1,       },     },     'postcss-loader',   ], }

This ensures that CSS files imported from other CSS files will be processed with postcss-loader as well.

After setting up postcss-loader, we’ll install postcss-nesting and include it in the PostCSS configuration:

yarn add postcss-nesting

There are many ways to configure PostCSS. In this case, we’re going to add a postcss.config.js file at the root of our project:

module.exports = {   plugins: {     "postcss-nesting": {},   }, }

Now, we can write a CSS file for our Photo component. Let’s call it Photo.css:

.photo {   width: 200px;   &.rounded {     border-radius: 1rem;   } }  @media (min-width: 30rem) {   .photo {     width: 400px;   } }

Let’s also add a file called utils.css that contains a class for visually hiding elements, as we covered in the the first part of this series:

.visuallyHidden {   border: 0;   clip: rect(0 0 0 0);   height: 1px;   margin: -1px;   overflow: hidden;   padding: 0;   position: absolute;   width: 1px;   white-space: nowrap; }

Since our component relies on this utility, let’s include utils.css to Photo.css by adding an @import statement to the top:

@import url('utils.css');

This will ensure that webpack requires utils.css, thanks to css-loader. We can place utils.css anywhere we want and adjust the @import path. In this particular case, it’s a sibling of Photo.css.

Next, let’s import Photo.css into our JavaScript file and use the classes to style our component:

import React from 'react' import { getSrc, getSrcSet } from './utils' import './Photo.css'  const Photo = ({ publicId, alt, rounded }) => (   <figure>     <img       className={rounded ? 'photo rounded' : 'photo'}       src={getSrc({ publicId, width: 200 })}       srcSet={getSrcSet({ publicId, widths: [200, 400, 800] })}       sizes="(min-width: 30rem) 400px, 200px"     />     <figcaption className="visuallyHidden">{alt}</figcaption>   </figure> )  Photo.defaultProps = {   rounded: false, }  export default Photo

While this will work, our class names are way too simple and they will most certainly clash with others completely unrelated to our .photo class. One of the ways of working around this is using a naming methodology, like BEM, to rename our classes (e.g. photo_rounded and photo__what-is-this--i-cant-even) to help prevent clashes from happening, but components quickly get complex and class names tend to get long, depending on the overall complexity of the project.

Meet CSS Modules.

CSS Modules

Simply put, CSS Modules are CSS files in which all class names and animations are scoped locally by default. They look a lot like regular CSS. For example, we can use our Photo.css and utils.css files as CSS Modules without modifying them at all, simply by passing modules: true to css-loader’s options:

{   loader: 'css-loader',   options: {     importLoaders: 1,     modules: true,   }, }

CSS Modules are an evolving feature and could be discussed at even greater length. Robin’s three-part series on it is a good overview and introduction.

While CSS Modules themselves look very similar to regular CSS, the way we use them is quite different. They are imported into JavaScript as objects where keys correspond to authored class names, and values are unique class names that are auto-generated for us that keep the scope limited to a component:

import React from 'react' import { getSrc, getSrcSet } from './utils' import styles from './Photo.css' import stylesUtils from './utils.css'  const Photo = ({ publicId, alt, rounded }) => (   <figure>     <img       className={rounded         ? `$  {styles.photo} $  {styles.rounded}`         : styles.photo}       src={getSrc({ publicId, width: 200 })}       srcSet={getSrcSet({ publicId, widths: [200, 400, 800] })}       sizes="(min-width: 30rem) 400px, 200px"     />     <figcaption className={stylesUtils.visuallyHidden}>{alt}</figcaption>   </figure> )  Photo.defaultProps = {   rounded: false, }  export default Photo

Since we’re using utils.css as a CSS Module, we can remove the @import statement at the top of Photo.css. Also, notice that using camelCase to format class names makes them easier to use in JavaScript. If we had used dashes, we’d have to write things out in full, like stylesUtils['visually-hidden'].

CSS Modules have additional features, like composition. Right now, we’re importing utils.css into Photo.js to apply our component styles, but let’s say that we want to shift the responsibility of styling the caption to Photo.css instead. That way, as far as our JSX code is concerned, styles.caption is just another class name; it just so happens to visually hide the element, but it might be styled differently in the future. Either way, Photo.css will be making those decisions.

So let’s add a caption style to Photo.css to extend the properties of the visuallyHidden utility using composes:

.caption {   composes: visuallyHidden from './utils.css'; }

We could just as well add more rules to that class, but this is all we need in this case. Now, we no longer need to import utils.css into Photo.js; we can simply use styles.caption instead:

<figcaption className={styles.caption}>{alt}</figcaption>

How does this work? Do the styles from visuallyHidden get copied over to caption? Let’s examine the value of styles.caption — whoa, two classes! That’s right: one is from visuallyHidden and the other one will apply any other styles we add to caption. CSS-in-JS makes it too easy to duplicate styles with libraries, like polished, but CSS Modules encourage you to reuse existing styles. No need to create a new VisuallyHidden React component to only apply several CSS rules.

Let’s take it even further by examining this uncomfortable class composition:

rounded   ? `$  {styles.photo} $  {styles.rounded}`   : styles.photo

There are libraries for these situations, like classnames, which are useful for more complex class composition. In our example, though, we can keep on using composes and rename .rounded to .roundedPhoto:

.photo {   width: 200px; }  .roundedPhoto {   composes: photo;   border-radius: 1rem; }  @media (min-width: 30rem) {   .photo {     width: 400px;   } }  .caption {   composes: visuallyHidden from './utils.css'; }

Now we can apply the class names to our component in a much more readable fashion:

rounded ? styles.roundedPhoto : styles.photo

But wait, what if we accidentally place the .roundedPhoto ruleset before .photo and some rules from .photo end up overriding rules from .roundedPhoto due to specificity? Don’t worry, CSS Modules prevent us from composing classes defined after the current class by throwing an error like this:

referenced class name "photo" in composes not found (2:3)    1 | .roundedPhoto { > 2 |   composes: photo;     |   ^   3 |   border-radius: 1rem;   4 | }

Note that it’s generally a good idea to use a file naming convention for CSS Modules, for example using the extension .module.css, because it’s common to want to apply some global styles as well.

Dynamic styles

So far, we’ve been conditionally applying predefined sets of styles, which is called conditional styling. What if we also want to be able to fine-tune the border radius of the rounded photos? This is called dynamic styling because we don’t know what the value is going to be in advance; it can change while the application is running.

There aren’t many use cases for dynamic styling — usually we’re styling conditionally, but in cases when we need this, how would we approach this? While we could get by with inline styles, a native solution for this type of problems is custom properties (a.k.a. CSS variables). A really valuable aspect of this feature is that browsers will update styles using custom properties when JavaScript changes them. We can set a custom property on an element through inline styles, which means that it will be scoped to that element and that element only:

style={typeof borderRadius !== 'undefined' ? {   '--border-radius': borderRadius, } : null}

In Photo.css, we can use this custom property by using var() and passing the default value as the second argument:

.roundedPhoto {   composes: photo;   border-radius: var(--border-radius, 1rem); }

As far as JavaScript is concerned, it’s only passing a dynamic parameter to CSS, then when CSS takes over, it can apply the value as-is, calculate a new value from it using calc(), etc.


At the time of this writing, the browser support for custom properties is… well, you decide for yourself. Not supporting these browsers is (probably) out of the question for a real-world application, but keep in mind that some styles are less important than others. In this case, it’s not a big deal if the border radius on IE is always 1rem. The application doesn’t have to look the same way on every browser.

The way we can automatically provide fallbacks for all custom properties is to install postcss-custom-properties and add it to our PostCSS configuration:

yarn add postcss-custom-properties
module.exports = {   plugins: {     'postcss-nesting': {},     'postcss-custom-properties': {},   }, }

This will generate a fallback for our border-radius rule:

.roundedPhoto {   composes: photo;   border-radius: 1rem;   border-radius: var(--border-radius, 1rem); }

Browsers that don’t understand var() will ignore that rule and use the previous one. Don’t let the name of the plugin fool you; it only partially improves the support for custom properties by providing static fallbacks. The dynamic aspect can’t be polyfilled.

Exposing values to JavaScript

In the previous part of this series, we explored how CSS-in-JS allows us to share almost anything between CSS and JavaScript, using media queries as an example. There is no possible way to achieve this here, right?

Thanks to Jonathan Neal, you can!

First, meet postcss-preset-env, the successor to cssnext. It’s a PostCSS plugin that acts as a preset similar to @babel/preset-env. It contains plugins like postcss-nesting, postcss-custom-properties, autoprefixer etc. so we can use future CSS today. It splits the plugins across four stages of standardization. Some of the features I’d like to show you aren’t included in the default range (stage 2+), so we’ll explicitly enable the ones we need:

yarn add postcss-preset-env
module.exports = {   plugins: {     'postcss-preset-env': {       features: {         'nesting-rules': true,         'custom-properties': true, // already included in stage 2+         'custom-media-queries': true, // oooh, what's this? :)       },     },   }, }

Note that we replaced our existing plugins because this postcss-preset-env configuration includes them, meaning our existing code should work the same as before.

Using custom properties in media queries is invalid because that’s not what they were designed for. Instead we’ll use custom media queries:

@custom-media --photo-breakpoint (min-width: 30em);  .photo {   width: 200px; }  @media (--photo-breakpoint) {   .photo {     width: 400px;   } }

Even though this feature is in the experimental stage and therefore not supported in any browser, thanks to postcss-preset-env it just works! One catch is that PostCSS operates on a per-file basis, so this way only Photo.css can use --photo-breakpoint. Let’s do something about that.

Jonathan Neal recently implemented an importFrom option in postcss-preset-env, which is passed to other plugins that support it as well, like postcss-custom-properties and postcss-custom-media. Its value can be many things, but for the purpose of our example, it’s a path to a file that will be imported to the files PostCSS processes. Let’s call this one global.css and move our custom media query there:

@custom-media --photo-breakpoint (min-width: 30em);

…and let’s define importFrom, providing the path to global.css:

module.exports = {   plugins: {     'postcss-preset-env': {       importFrom: 'src/global.css',       features: {         'nesting-rules': true,         'custom-properties': true,         'custom-media-queries': true,       },     },   }, }

Now we can delete the @custom-media line at the top of Photo.css and our --photo-breakpoint value will still work, because postcss-preset-env will use the one from global.css to compile it. Same goes for custom properties and custom selectors.

Now, how to expose it to JavaScript? When experimental features like custom media queries get standardized and implemented in major browsers, we will be able to retrieve them natively from CSS. For example, this is how we would access a custom property called --font-family defined on :root:

const rootStyles = getComputedStyle(document.body) const fontFamily = rootStyles.getPropertyValue('--font-family')

If custom media queries get standardized we will probably be able to access them in a similar way, but in the meantime we have to find an alternative. We could use the exportTo option to generate a JavaScript or JSON file, which we would import into JavaScript. However, that option wasn’t designed for this workflow because webpack would try to require it before it’s generated. Even if we generated it before running webpack, every update to global.css would cause webpack to re-compile twice, once to generate the output file, and once more to import it. I wanted a solution that’s unencumbered by its implementation.

For this series, I’ve created a brand new webpack loader called css-customs-loader just for you! It makes this task easy: all we need to is include it in our webpack configuration before css-loader:

{   test: /\.css$  /,   use: [     'style-loader',     'css-customs-loader',     {       loader: 'css-loader',       options: {         importLoaders: 1,       },     },     'postcss-loader',   ], }

This exposes custom media queries, as well as custom properties, to JavaScript. We can access them simply by importing global.css:

import React from 'react' import { getSrc, getSrcSet } from './utils' import styles from './photo.module.css' import { customMedia } from './global.css'  const Photo = ({ publicId, alt, rounded, borderRadius }) => (   <figure>     <img       className={rounded ? styles.roundedPhoto : styles.photo}       style={         typeof borderRadius !== 'undefined'           ? { ['--border-radius']: borderRadius }           : null       }       src={getSrc({ publicId, width: 200 })}       srcSet={getSrcSet({ publicId, widths: [200, 400, 800] })}       sizes={`$  {customMedia['--photo-breakpoint']} 400px, 200px`}     />     <figcaption className={styles.caption}>{alt}</figcaption>   </figure> )  Photo.defaultProps = {   rounded: false, }  export default Photo

That’s it!

I created a repository demonstrating all of the concepts discussed in this series. Its readme also contains some advanced tips about the approach described in this post.

View Repo


It’s safe to say that tools like CSS Modules and PostCSS and upcoming CSS features are up to the task of dealing with many challenges of CSS. Whichever side of the CSS debate you’re on, this approach is worth exploring.

I have a strong CSS-in-JS background, but I’m very susceptible to hype, so keeping up with that world is hard. Which library should I use now, styled-components or emotion? Also, while having styles next to the behavior can be succinct, it’s also mixing two very different languages — CSS is very verbose compared to JavaScript. This incentivized me to write less CSS because I wanted to avoid getting the file too crowded. This may be a matter of personal preference, but I didn’t want that to be an issue. Using a separate file for CSS finally gave my code some air.

While mastering this approach may not be as straightforward as CSS-in-JS, I believe it’s more rewarding in the long run. It will improve your CSS skills and make you better prepared for its future.

Article Series:

  1. CSS-in-JS
  2. CSS Modules, PostCSS and the Future of CSS (This post)

The post Bridging the Gap Between CSS and JavaScript: CSS Modules, PostCSS and the Future of CSS appeared first on CSS-Tricks.


, , , , ,