Carbon’s 2021 release: April update

We’re excited to share updates about the next major release of Carbon!

In November we shared that we’re targeting the next major release of the Carbon Design System in 2021. The release will focus on quality of life updates for designers and developers including token and prop renaming for ease of use, component API updates for a more predictable developer experience, and introducing CSS grid for accurate layout building in line with the IBM Design Language.

And with no changes to the branding or the design language, the release will not require any brand-driven product redesigns. Teams will be free to update at their convenience!

Today, we’re excited to share the first round of updates to highlight what to expect from this release and what you can do to get ready.

Design Tokens

We reviewed our color token naming and realized that our terminology and naming conventions were a little confusing. We’d heard that you often had to reference our guide to know how to accurately apply tokens to your work. For example, text-03 tells you that it's meant to be used as text color, but what kind of text color?

We investigated different ways to represent token usage in the name and make them easier to apply. We came up with two new naming conventions and shared them as a discussion on GitHub with our community. We received great feedback on this discussion, as well as the discussion about our color layering model. Thank you to everyone who participated!

To keep the names as simple and straightforward as possible, we decided on a blend of the two conventions.

In our alpha release, you’ll find these tokens in our themes package and also in our components as we begin to update them with the new set. They will also be available in an alpha Sketch kit library.

To view a full list of the new tokens, check out our Notion Page.

Bringing in CSS Grid

One of the technologies we’re most excited to bring into Carbon is CSS grid. We’ve had a lot of success with our current Flexbox-based implementation, but with CSS grid we’re finally bringing in support for sub-grid and a bunch of other features that come along with using this new technology.

If you’re using our Grid, Row, or Column components today in React then what you have today will look almost exactly the same. The only difference will be that you no longer will need the Row components. You can just drop Column components directly into Grid. You can also keep using Row and everything will keep working as intended.

Carbon and Sass

One of the biggest changes coming to the project is the change from node-sass to sass. This decision was made after the announcement in the blog post, LibSass is deprecated. Like many of you who use Sass, we’ve relied heavily on LibSass through projects like node-sass. We would not be where we are today without all the hard work and effort that went into these projects but it’s time to move on to the next plan.

Sass Modules

With the transition to using sass, Carbon will begin targeting Sass modules in this release. This new module system was introduced in 2019 and we knew that it would be a great fit for the way Carbon authors and ships Sass files.

If you’re using Carbon today, this update will result in two changes:

• You now will use the @use keyword instead of @import to include Carbon in your project.
• Certain import paths will change as a result of this transition.

Some smaller changes will come along with using this new module system, but they will not impact most teams.

All about compile times

This release is also an opportunity to improve the compile times for projects that use Carbon. This issue has understandably been brought up by teams as a frustrating part of their development experience but there were few options we could offer that would work with our existing Sass setup and API. We wanted to drastically improve the performance in this release.

The good news is that many of the structural challenges we were dealing with will be addressed through our use of Sass modules. When profiling early builds of our codebase converted to Sass modules, we saw a ~90% reduction in average recompilation times using sass-loader and around a 60% reduction in initial build times.

We can’t wait to bring this change to you!

Next steps

For teams using Sass with Carbon today, here’s how you can get ahead of this change.

• For most projects, switching from node-sass to sass is as simple as changing the dependency.
• For projects that use webpack with sass-loader, it should pick up this change automatically.
• For projects using create-react-app or Next.js, you will need to remove node-sass from your dependencies and add sass as the replacement.

If you’re interested in previewing the Sass module version of Carbon, you can join our release partner program — see the details below!

Goodbye bx, our old friend

We’ve used bx to prefix our CSS selectors ever since IBM Cloud was called Bluemix. In this release, we decided it was time to migrate from this prefix to cds, short for Carbon Design System.

The prefix will be used in our CSS selectors, along with other aspects of our CSS like Custom Properties.

Our goal is to ship tooling to help teams update their prefix, but here are some steps you can try out today to move towards the new prefix.

For most teams, you can preview the impact of this change by setting the $prefix variable before bringing in Carbon. For example:

$prefix: 'cds';
@import 'carbon-components/scss/globals/scss/styles.scss';

This change will result in Carbon using the cds prefix for every selector in the codebase and will help you identify where in your codebase you may be relying on bx directory.

Changes coming to icons

One of the largest changes that came to Carbon in v10 was the set of icons that we supported. This set grew tremendously due to the hard work of the brand team at IBM, and we went from supporting around 150 icons to over 1600 as a result.

Each icon has four sizes and in our current implementation of icon packages, we export each of these sizes as an individual asset. For example, the add icon will export Add16, Add20, Add24, and Add32.

The package size quickly ballooned as we went from around 150 exports in code to over 6000, and this lead to several challenges. One question was how we could set teams up for success when it comes to effectively tree-shaking unused icons. We also realized that the export-per-size approach wasn’t the right fit for how teams were using our icons.

We landed on streamlining the API of these icon components to include a size prop. Now, instead of having to use the explicit export for size, you can pass in the size to the component: <Add size={24} />.

We’ve also kept the changes we made to our entry point to help with tree-shaking, along with making it easier than ever to directly include an icon in your project.

Release partners

As the team works towards this 2021 release, we want to engage with teams using Carbon to try out parts of our release to make sure that we’re heading in the right direction.

If you’re interested in previewing and giving feedback on any of the work described here, or want to help influence our direction, we’d love to hear from you.

Directions for joining are over on GitHub. We’re working with internal teams at IBM currently but would love to expand this to include external teams as well!

What’s coming next

After these first updates, we’ll be working towards our beta release. This release will include component updates, accessibility component primitives, component API improvements, and more!

If you’d like to help us out along the way, definitely join our release partner program. Otherwise, be on the lookout for the public preview release available in the coming months!

Josh Black is a Software Engineer based out of Austin, TX working on the Carbon Design System. The above article is personal and does not necessarily represent IBM’s positions, strategies, or opinions.

Questions or comments about Carbon? Reach out at carbon@us.ibm.com or tweet us @_carbondesign.