Sass Blog

Page 4 of 9

Previous page

• Request for Comments: First-Class Calc

  Posted 15 March 2021 by Natalie Weizenbaum

  One of the absolutely most-requested features in Sass is the ability to more easily work with calc() expressions. These expressions have historically been parsed opaquely: between the parentheses, you can put any text at all, and Sass will just treat it as an unquoted string. This has simplified Sass’s parser, since we don’t have to support the specific calc() microsyntax, and it’s meant that we automatically support new features like the use of CSS variables within calc().

  However, it comes at a substantial usability cost as well. Because each calc() is totally opaque to Sass’s parser, users can’t simply use Sass variables in place of values; they have to interpolate variables explicitly. And once a calc() expression has been created, there’s no way to manipulate it with Sass the way you can manipulate a plain number.

  We’re looking to change that with a new proposal we call “First-Class Calc”. This proposal changes calc() (and other supported mathematical functions) from being parsed as unquoted strings to being parsed in-depth, and…

• LibSass is Deprecated

  Posted 26 October 2020 by Natalie Weizenbaum

  After much discussion among the Sass core team, we’ve come to the conclusion that it’s time to officially declare that LibSass and the packages built on top of it, including Node Sass, are deprecated. For several years now, it’s been clear that there’s simply not enough engineering bandwidth behind LibSass to keep it up-to-date with the latest developments in the Sass language (for example, the most recent new language feature was added in November 2018). As much as we’ve hoped to see this pattern turn around, even the excellent work of long-time LibSass contributors Michael Mifsud and Marcel Greter couldn’t keep up with the fast pace of language development in both CSS and Sass.

  I’ll go into detail about what this means below, but here are the major points:

  • We no longer recommend LibSass for new Sass projects. Use Dart Sass instead.

  • We recommend all existing LibSass users make plans to eventually move onto Dart Sass, and that all Sass libraries make plans to eventually drop support for LibSass….

• Request for Comments: HWB Functions

  Posted 7 October 2020 by Natalie Weizenbaum

  The CSS working group has been up to all sorts of exciting stuff recently in the Color Level 4 spec, and the Sass team is starting to think about how to integrate those cool new features into Sass’s color model. We need more time to hammer out exactly the right designs for complex features like the Lab color space, but that doesn’t mean we can’t add a few new color goodies.

  Today we’re announcing a proposal for one such feature: built-in Sass functions for HWB colors! Once this proposal (drafted by Sass core team member Miriam Suzanne) is accepted and implemented, you’ll be able to write colors in HWB syntax and adjust their whiteness and blackness the same way you can adjust a color’s saturation and lightness today.

  The FunctionsThe Functions permalink

  Here are the new and improved functions this proposal adds:

  color.hwb()color.hwb() permalink

  The color.hwb() function defines a color using its hue, whiteness, and blackness. Like the existing rgb() and hsl() functions, It can either use…

• Request for Comments: Nested Map Functions

  Posted 16 September 2020 by Natalie Weizenbaum

  As Sass libraries and design systems get more complex and have more users with different needs, they tend to develop the need to share and override configuration and design tokens. This configuration is often hierarchical, and ends up being represented as maps that contain maps that contain still more maps. Up until now, Sass’s map functions haven’t really made it easy to work with this sort of nested map structure. But that’s changing with the latest language proposal, written by Sass core team member Miriam Suzanne.

  This proposal expands the existing map functions and adds a few new ones to make working with nested maps much easier than it was before. It’s based on helper functions that pop up in all sorts of Sass projects around the web, incorporating best practices back into the language itself.

  The FunctionsThe Functions permalink

  Here are the new and improved functions this proposal adds:

  map.get() and map.has-key()map.get() and map.has-key() permalink

  The map.get() and map.has-key() functions both now take any number of…

• The Module System is Launched

  Posted 2 October 2019 by Natalie Weizenbaum

  The Sass team has known for years that the @import rule, one of the earliest additions to Sass, wasn’t as good as we wanted it. It caused a litany of problems for our users:

  • It was next to impossible to figure out where a given variable, mixin, or function (collectively called “members”) was originally defined, since anything defined in one stylesheet was available to all stylesheets that were imported after it.

  • Even if you chose to explicitly import every stylesheet that defined members you used, you’d end up with duplicate CSS and strange side-effects, because stylesheets were reloaded from scratch every time they were imported.

  • It wasn’t safe to use terse and simple names because there was always a possibility that some other stylesheet elsewhere in your application would use the same name and mess up your logic. To be safe users had to manually add long, awkward namespaces to everything they defined.

  • Library authors had no way to ensure that their private helpers wouldn’t be accessed by downstream users,…

Next page