Sass Blog

LibSass Has Reached End-Of-Life

2025-10-23T00:15:00Z

LibSass and the packages built on top of it have been deprecated since October 2020. In the five years since we made that announcement, the Sass language has continued to evolve to support the latest CSS features like color spaces, and embedded sass made it easy to run Dart Sass across numerous different languages and platforms.^[1] Dart Sass now meets essentially all the use-cases that LibSass once did.

At the same time, development of LibSass has faltered. There hasn't been a new commit to the source code repository since December 2023, and there are numerous issues languishing unaddressed. The time has come to be clear: LibSass is no longer maintained and will receive no future updates.

Migrating AwayMigrating Away permalink

As they say, the best time to migrate away from LibSass was five years ago, but the second best time is now. There is a large and growing list of incompatibilities between it and Dart Sass, largely to more correctly support CSS features. You'll need to make sure your stylesheets are building without deprecation warnings and then do some visual checks as well to see if there are any more subtle differences.

The LibSass page contains a summary of the most notable incompatibilities, which may be helpful in knowing what to look for. Some of them also have automated migrations available using the Sass migrator.

Thanks AgainThanks Again permalink

I already mentioned this in the deprecation blog post, but thanks to everyone who made LibSass happen. It was a crucial stepping stone to bring Sass outside the Ruby bubble at a time when it was no longer the center of the web development world, and I don't think it's an exaggeration to say that Sass is still the world's most popular stylesheet preprocessor because of LibSass. But all things that rise must also fall, and this project's time has come.

Intrepid Sass contributor Natsuki is even working on a way to run it on platforms the Dart VM doesn't support, like BSD variants, by driving the embedded protocol using Node.js! ↩︎

Request for Comments: Indented Syntax Improvements

2024-12-03T23:30:00Z

For users of the indented syntax (.sass), there has been a long standing request for the ability to have line breaks that don't end a statement. Certain CSS syntaxes like grid-template and @font-face src declarations are long, and line breaks can greatly increase the readability of the styles.

There have been many suggestions, several attempts, and numerous workarounds to address this pain point. We are proposing several new syntax options in the indented syntax that add considerable flexibility and look to address this as part of the language.

Multiline statementsMultiline statements permalink

We propose allowing statements in the indented syntax to span multiple lines, as long as line breaks occur in places where the statement can't end.

A common way of using this syntax will be wrapping lists with line breaks in parentheses. This allows for a grid-template declaration on multiple lines.

.grid
  display: grid
  grid-template: (
    "header" min-content
    "main" 1fr
  )

As usual, these parentheses will not be included in the output.

.grid {
  display: grid;
  grid-template: "header" min-content "main" 1fr;
}

Powering this change is the underlying rule that linebreaks only end statements where it's valid for a statement to end. Anywhere where a statement can't end, a linebreak is ignored. This means that if the parser can't tell whether or not a linebreak is intended to end a statement, it will end the statement.

This example demonstrates several places where line breaks will not end statements.

@each $item in /* A statement can't end after the word "in" in an `@each` statement. */
    1, 2, 3
  .item-#{ 
    $item /* A statement can't end inside the curly braces in an interpolation. */
  }
    content: $item * /* A statement can't end after a multiplication operator. */
        10

As a counter example, here are some places in the same stylesheet where linebreaks could end statements. These linebreaks will cause compilation errors because the next line is not able to be parsed.

Important! This code snippet demonstrates what will NOT work.

@each $item in 1, /* A statement can end after a value, even in the middle of a list. */
     2, 3
  .item-#{ $item }
    content: $item /* A statement can end after a value, and does not look ahead for operators. */
      * 10

Semicolons are also allowedSemicolons are also allowed permalink

Another proposed change would allow semicolons to optionally be added at the end of statements in the indented syntax. Indentation rules still apply, so you won't be able to separate multiple statements on the same line, even with a semicolon.

No breaking changesNo breaking changes permalink

These changes are opt-in, and authors who don't want to use the new syntax do not have to. No changes need to be made to existing stylesheets written in the indented syntax.

An update to the proposalAn update to the proposal permalink

An earlier version of this post proposed a "SCSS-in-Sass" format. After feedback from tool maintainers, this has been removed from the proposal, but we welcome feedback on the Github issue.

Next stepsNext steps permalink

This is still in the proposal phase, and we are open to feedback. Review the proposal on Github, and open an issue with any thoughts or concerns you may have.

In addition to feedback from authors using the indented syntax, we are also interested in hearing from maintainers of tooling that supports the indented syntax.

`@import` is Deprecated

2024-10-17T01:00:00Z

Back in 2019, we released the Sass module system, adding new @use and @forward rules to the language that were designed to replace @import and make stylesheets more maintainable and less error-prone. We can now announce that @import is officially deprecated as of Dart Sass 1.80.0.

The module system ensures that it's easy for both developers and tooling to determine where a given Sass member is defined, adds namespacing to prevent the need to manually add long, awkward namespaces to names, and allows library authors to ensure their private helpers can't be accessed by downstream users. Additionally, since each module is only ever loaded once, depending on the same stylesheet multiple times no longer results in duplicated CSS.

With 4.5 years since we released the module system and more than a year since we passed the 80% Dart Sass usage share threshold we set for starting this deprecation, we feel comfortable making this move. However, we understand that this is a big change to the language and not all users have been able to fully migrate off of @import so far.

Controlling Deprecation WarningsControlling Deprecation Warnings permalink

While users should treat this deprecation as a signal to migrate sooner rather than later, for anyone who wishes to silence deprecation warnings for @import, we recently added a new --silence-deprecation command line option. Just pass --silence-deprecation=import to Sass and you won't have to worry about the deprecation warnings while you complete the migration. Equivalent options exist in the JS and Dart APIs.

On the other hand, users who have already migrated to the module system and wish to prevent any backsliding can use the --fatal-deprecation=import to treat any Sass @import rules as errors.

TimelineTimeline permalink

As previously announced, given the size of this change, we expect to wait at least a two years after this deprecation before we remove @import from the language. While we plan to release Dart Sass 2.0.0 soon with other, smaller breaking changes, that release will not include any changes to @import. Instead, we expect @import to be removed in Dart Sass 3.0.0.

MigratorMigrator permalink

Users migrating off of @import can use the Sass migrator to move to the module system. Follow the instructions to install it, then run it on your application:

$ sass-migrator module --migrate-deps <path/to/style.scss>

Built-in FunctionsBuilt-in Functions permalink

Alongside this deprecation, we are also deprecating any uses of global built-in Sass functions that are now available in built-in modules. In the past, we've had a number of conflicts between these functions and new plain CSS function names, and moving to the module system will help us avoid further conflicts in the future.

The global-builtin ID can be passed to the --silence-deprecation or --fatal-deprecation flags on its own, or in combination with import. This deprecation will follow the same timeline as @import for removal. For users who want to migrate off of global functions but aren't ready to complete the module system migration, we've also added a new --built-in-only flag to the module system migrator.

Sass color spaces & wide gamut colors

2024-09-11T21:00:00Z

Wide gamut colors are coming to Sass!

I should clarify. Wide gamut CSS color formats like oklch(…) and color(display-p3 …) have been available in all major browsers since May, 2023. But even before that, these new color formats were allowed in Sass. This is one of my favorite features of Sass: most new CSS just works, without any need for "official" support or updates. When Sass encounters unknown CSS, it passes that code along to the browser. Not everything needs to be pre-processed.

Often, that's all we need. When Cascade Layers and Container Queries rolled out in browsers, there was nothing more for Sass to do. But the new CSS color formats are a bit different. Since colors are a first-class data type in Sass, we don't always want to pass them along as-is. We often want to manipulate and manage colors before they go to the browser.

Already know all about color spaces? Skip ahead to the new Sass features!

The color format trade-offThe color format trade-off permalink

CSS has historically been limited to sRGB color formats, which share two main features:

They use an underlying RGB color model for representing & manipulating colors mathematically by controlling the relative amounts of red, green, and blue light.
They can only represent colors in the sRGB color gamut -- the default range of color that can be displayed on color monitors since the mid 1990s.

Clear gamut boundariesClear gamut boundaries permalink

The previously available formats in CSS -- named colors (e.g. red), hex colors (e.g. #f00), and color functions (e.g. rgb()/rgba(), hsl()/hsla(), and more recently hwb()) -- are all ways of describing sRGB colors. Named colors are special, but the other formats use a 'coordinate' system, as though the colors of the gamut were projected into 3d space:

Images generated using ColorAide by Isaac Muse.

Look at those nice, geometric shapes! RGB gives us a rainbow cube, while HSL and HWB (with their "polar" hue channels) arrange those same colors into cylinders. The clean boundaries make it easy for us to know (mathematically) what colors are in gamut or out of gamut. In rgb() we use values of 0-255. Anything inside that range will be inside the cube, but if a channel goes below 0 or above 255, we're no longer inside the sRGB gamut. In hsl() and hwb() the hue coordinates can keep going around the circle without ever reaching escape velocity, but the saturation, lightness, whiteness, and blackness channels go cleanly from 0-1 or 0%-100%. Again, anything outside that range is outside the color space.

Matching human perceptionMatching human perception permalink

But that simplicity comes with limitations. The most obvious is that monitors keep getting better. These days, many monitors can display colors beyond sRGB, especially extending the range of bright greens available. If we simply extend our shapes with the new colors available, we're no longer dealing with clean geometry!

The crisp edges and clean math of sRGB formats were only possible because we knew exactly what colors could be displayed, and we arranged those colors to fit perfectly into a box. But human color perception is not so clear-cut, and it doesn't align perfectly with the gamut of any monitors on the market. When we attempt to space all the same colors evenly based on human perception rather than simple math, we get an entirely different shape with swooping edges. This is the display-p3 gamut in oklch space:

The practical difference is particularly noticeable when we compare colors of the same 'lightness' in hsl vs oklch. Humans perceive yellow hues as lighter than blues. By scaling them to fit in the same range, hsl gives us a yellow that is much brighter than the blue:

New CSS formats give us the choiceNew CSS formats give us the choice permalink

Moving forward, there are two directions we could go with wide gamut colors:

Color formats that re-fit larger and larger gamuts into simple coordinates, stretching the colors to preserve clean, geometric boundaries.
Color formats that maintain their perceptually uniform spacing, without any regard for specific gamuts.

On the one hand, clean boundaries allow us to easily stay inside the range of available colors. Without those boundaries, it would be easy to accidentally request colors that aren't even physically possible. On the other hand, we expect these colors to be perceived by other humans -- and we need to make things look consistent, with enough contrast to be readable.

The CSS Color Module Level 4 defines a number of new CSS color formats. Some of them maintain geometric access to specific color spaces. Like the more familiar rgb() and hsl() functions, the newer hwb() function still describes colors in the sRGB gamut, using hue, whiteness, and blackness channels. It's an interesting format, and I've written about it before.

The rest of the gamut-bounded spaces are available using the color(<space> <3-channels> / <alpha>) function. Using that syntax we can define colors in sRGB, srbg-linear, display-p3 (common for modern monitors), a98-rgb, prophoto-rgb, and rec2020. Each of these maps the specified gamut onto a range of (cubic) coordinates from 0-1 or 0%-100%. Nice and clean.

In the same color() function, we can also access the 'device independent' (and gamut-less) xyz color spaces -- often used as an international baseline for converting between different color models. I won't get into white points here, but we can specify xyz-d65 (the default) explicitly, or use xyz-d50 instead.

Working outwards from xyz, we get a number of new theoretically unbounded color formats -- prioritizing perceptually uniform distribution over clean geometry. These are available in functions of their own, including lab() (lightness, a, and b) and lch() (lightness, chroma, and hue) along with the newer 'ok' versions of each -- oklab() and oklch(). If you want the full history of these formats, Eric Portis has written a great explainer.

TL;DR top priority new formatsTL;DR top priority new formats permalink

For the color experts, it's great to have all this flexibility. For the rest of us, there are a few stand-out formats:

color(display-p3 …) provides access to a wider gamut of colors, which are available on many modern displays, while maintaining a clear set of gamut boundaries.
oklch(…) is the most intuitive and perceptually uniform space to work in, a newer alternative to hsl(…) -- chroma is very similar to saturation. But there are few guard rails here, and it's easy to end up outside the gamuts that any screen can possibly display. The coordinate system is still describing a cylinder, but the edges of human perception and display technology don't map neatly into that space.
For transitions and gradients, if we want to go directly between hues (instead of going around the color wheel), oklab(…) is a good linear option. Usually, a transition or gradient between two in-gamut colors will stay in gamut -- but we can't always rely on that when we're dealing with extremes of saturation or lightness.

CSS color functions in SassCSS color functions in Sass permalink

Sass now accepts all the new CSS formats, and treats them as first-class colors that we can manipulate, mix, convert, and inspect. These functions are all available globally:

lab(), oklab(), lch(), and oklch()
color() using the sRGB, srgb-linear, display-p3, a98-rgb, prophoto-rgb, rec2020, xyz, xyz-d65, and xyz-d50 color spaces
hwb() (Sass previously had a color.hwb() function, which is now deprecated in favor of the global function)

The Sass color functions use the same syntax as the CSS functions, which means that a given color can be represented in a variety of different spaces. For example, these are all the same color:

Sass Blog

LibSass Has Reached End-Of-Life

Migrating AwayMigrating Away permalink

Thanks AgainThanks Again permalink

Request for Comments: Indented Syntax Improvements

Multiline statementsMultiline statements permalink

Semicolons are also allowedSemicolons are also allowed permalink

No breaking changesNo breaking changes permalink

An update to the proposalAn update to the proposal permalink

Next stepsNext steps permalink

`@import` is Deprecated

Controlling Deprecation WarningsControlling Deprecation Warnings permalink

TimelineTimeline permalink

MigratorMigrator permalink

Built-in FunctionsBuilt-in Functions permalink

Sass color spaces & wide gamut colors

The color format trade-offThe color format trade-off permalink

Clear gamut boundariesClear gamut boundaries permalink

Matching human perceptionMatching human perception permalink

New CSS formats give us the choiceNew CSS formats give us the choice permalink

TL;DR top priority new formatsTL;DR top priority new formats permalink

CSS color functions in SassCSS color functions in Sass permalink

SCSS Syntax

Sass Syntax

Sass colors hold their spaceSass colors hold their space permalink

SCSS Syntax

Sass Syntax

SCSS Syntax

Sass Syntax

SCSS Syntax

Sass Syntax

SCSS Syntax

Sass Syntax

SCSS Syntax

Sass Syntax

Manipulating Sass colorsManipulating Sass colors permalink

SCSS Syntax

Sass Syntax

SCSS Syntax

Sass Syntax

Working with gamut boundariesWorking with gamut boundaries permalink

SCSS Syntax

Sass Syntax

SCSS Syntax

Sass Syntax

Deprecated functionsDeprecated functions permalink

Node Sass is end-of-life

Announcing `pkg:` Importers

What is a pkg: importer?What is a pkg: importer? permalink

What do pkg: URLs look like?What do pkg: URLs look like? permalink

How do I publish an npm package that works with the Node.js pkg: importer?How do I publish an npm package that works with the Node.js pkg: importer? permalink

What is a `pkg:` importer?What is a pkg: importer? permalink

What do `pkg:` URLs look like?What do pkg: URLs look like? permalink

How do I publish an npm package that works with the Node.js `pkg:` importer?How do I publish an npm package that works with the Node.js pkg: importer? permalink