We've got another proposal out for review, this one for the JS API! We're planning to change the sourceMapIncludeSources option to clarify when and how source maps are embedded. Let us know what you think! https://github.com/sass/sass/blob/main/proposal/source-map-include-sources.md

@djenz yes, this definitely counts. thanks for the example!

A week ago, we put out a poll asking how many Sass users wrote CSS custom properties that weren't also valid SassScript (https://front-end.social/@sass/115272830411739760). About a third of you said you did, but no one gave examples. We'd love to know the specific use-cases you have for custom properties that use syntax that wouldn't be valid in other CSS properties!

In Sass today, CSS custom properties are parsed differently than other declarations. They don't allow normal SassScript—any variables and custom functions have to be wrapped in #{}. This is because the spec allows *anything* there, and it can be read from JS. But we're wondering: does anyone actually use this in practice? Remember that any value for any non-custom property is also valid SassScript. (Please share for broader reach!)

If you write CSS vars that aren't valid SassScript, we want to know details! Please reply with an example of the sorts of variables you're writing and why.

If we do change the way custom properties are parsed, it will be far in the future after a full deprecation cycle to make sure anyone who's using anything weird has a chance to migrate to something compatible. The main question right now is how we parse the `result` property in CSS `@function` rules, which has the same considerations as custom properties.

In Sass today, CSS custom properties are parsed differently than other declarations. They don't allow normal SassScript—any variables and custom functions have to be wrapped in #{}. This is because the spec allows *anything* there, and it can be read from JS. But we're wondering: does anyone actually use this in practice? Remember that any value for any non-custom property is also valid SassScript. (Please share for broader reach!)

We've got another proposal out for review, and this one's meaty! It proposes adding Sass support for the new plain CSS if() function in place of Sass's old if() function syntax. Let us know what you think! https://github.com/sass/sass/blob/main/proposal/plain-css-if.md

We've got another proposal for people to review! This one slightly changes the logic of which function names are reserved to better match CSS semantics and un-reserve some functions that are generally safe: https://github.com/sass/sass/blob/main/proposal/function-name.md

We've got another language proposal for the community to take a look at. This one proposes removing support for !default on private variables, since overriding them breaks the principle of encapsulation. Let us know what you think! https://github.com/sass/sass/blob/main/proposal/default-on-private-variables.md

We have a new language proposal out for review! This adds support for new syntax that's recently landed for the attr() function, which includes one breaking change: user-defined functions can no longer be named "type()". Check out the full proposal and let us know what you think! https://github.com/sass/sass/blob/main/proposal/attr-type.md

We've got an exciting new language proposal out for review that adds support for multiline expressions in the indented syntax. Take a look at the explainer at https://sass-lang.com/blog/rfc-indented-syntax/ and let us know what you think!

Thrilled to announce that after years of work, Dart Sass 1.79.0 has been released with support for wide-gamut color spaces! Read all about it in the blog post by @mia https://sass-lang.com/blog/wide-gamut-colors-in-sass/

We've got a new language proposal out for review. This one involves a breaking change in the way declarations are handled when interleaved with nested rules, so please take a look: https://github.com/sass/sass/blob/main/proposal/interleaved-declarations.md

We have a new, small proposal out for review. This deprecates mixins and functions beginning with "--" with the intention of making them errors in a future version, to avoid conflicting with plain-CSS functions and mixins. Let us know what you think! https://github.com/sass/sass/blob/main/proposal/css-function-mixin-preparation.md

We've got a new proposal out for public review! This one removes the meta.feature-exists() function, which hasn't had any few features added in years. See https://github.com/sass/sass/blob/main/proposal/remove-feature-exists.md for details, and let us know what you think!

We've got a new proposal out for review! This one adds a JS API for sharing resources between Sass compilations, specifically so embedded host users can get as much performance as possible.

https://github.com/sass/sass/blob/main/proposal/shared-resources.d.ts.md

Excited to announce that as of Sass 1.69.0, we now support first-class mixins! You can get a mixin as a value with meta.get-mixin(), and invoke it using the new built-in meta.apply() mixin. This allows mixins to be passed into libraries and dynamically invoked.

We've got another language proposal out for review! This one codifies "pkg:" as the URL scheme for Sass packages and adds a built-in loader for npm-style packages. https://sass-lang.com/blog/rfc-package-importer/

If you've been following along with our work on support for CSS Colors 4, you may be excited to know that we now have a parallel proposal out for review adding support for new color spaces to the JS API! https://github.com/sass/sass/blob/main/proposal/color-4-new-spaces-js.d.ts.md