Page 4 of 6
Posted 2 April 2018 by Natalie Weizenbaum
With the release of Dart Sass 1.0.0 stable last week, Ruby Sass was officially deprecated. I’ll continue to maintain it over the next year, but when 26 March 2019 rolls around it will reach its official end-of-life. I encourage all users to start migrating away sooner rather than later.
The Deprecation Period permalinkThe Deprecation Period permalink The Deprecation Period permalinkThe Deprecation Period
Over the next year, I’ll continue to work on Ruby Sass in a limited capacity. I’ll triage and fix any bugs that are reported, unless they’re minor or obscure enough to be unlikely to pose a practical problem over the next year. I’ll also add support for any new CSS features that require changes to the Sass parser or other parts of the language.
I also won’t be accepting pull requests for new Ruby Sass features. While pull requests are a great way to contribute…
Posted 26 March 2018 by Natalie Weizenbaum
I’ve just uploaded Dart Sass 1.0.0, the very first stable release, to GitHub, npm, Chocolatey, Homebrew, and pub. After working on it for almost two years, I’m thrilled to have a stable release out there and officially ready to use in real-world applications. All the reasons we chose Dart as the implementation language are bearing fruit: Dart Sass is much faster than Ruby Sass, much easier to make available across operating systems and language environments, and much more maintainable.
The 1.0.0 stable release indicates that Dart Sass is fully compatible with the Sass language as defined by the sass-spec test suite, and that its npm package is compatible with the Node Sass API, with the exception of source map support which is coming soon.
I’ve also updated sass-lang.com to cover Dart Sass. The release bar now shows the latest version of all three major implementations, as well as links to their release notes and documentation about each one. The install page covers Dart Sass instead…
Posted 7 July 2017 by Natalie Weizenbaum
I’m excited to announce that I’ve just released the stable version of Sass 3.5. This release focuses on compatibility with new CSS syntax, and helps lay the groundwork for the upcoming module system and compatibility with Dart Sass.
Most of the major features in 3.5 were already in the release candidate, which you can read about here. But there are a handful of other changes that have been added since then:
Sass now supports the the
::slotted()pseudo-element, including extending its selector arguments.
var()function may be safely passed to the CSS color functions
Transparent colors created by Sass’s color functions will now be written as
rgba(0, 0, 0, 0)rather than
transparentto work around a bug in Internet Explorer. Colors written as
transparentin the document will still be emitted as written.
Dart Sass Compatibility permalinkDart Sass Compatibility permalink Dart Sass Compatibility permalinkDart Sass Compatibility
I wrote last month about our plans for keeping Ruby Sass compatible with Dart Sass in…
Posted 5 June 2017 by Natalie Weizenbaum
Last weekend was three days long and the weather in Seattle was gorgeous. Contrary to stereotype, spring here is often characterized by bright sunny days that aren’t too hot, and on days like that I love to curl up on the armchair in my living room and write some code. This weekend, that meant finishing up the last few outstanding
@extend bugs, finally making Dart Sass fully sass-spec compatible1.
This is the milestone we’ve decided would mark the transition from alpha to beta releases of Dart Sass. Dart Sass 1.0.0-beta.1 is up now on npm, pub, and Chocolatey, and I encourage people to start trying it out in their own applications. We’ve fixed all the bugs we know about, so now we need our diligent users to find the rest of them and tell us!
Next Steps: Ruby Sass permalinkNext Steps: Ruby Sass permalink Next Steps: Ruby Sass permalinkNext Steps: Ruby Sass
There are a number of intentional behavior differences between Dart Sass and the existing implementations. All of these differences are things we think improve the language, and many of them…
Posted 11 February 2017 by Natalie Weizenbaum
One of the core design principles of Sass has always been to understand CSS as little as possible. As a CSS preprocessor of course we have to understand the syntax of CSS, but as much as we can we try to avoid caring about the semantics—the meaning behind the styles. This means that Sass has no idea which properties are valid, which HTML elements actually exist, or even to a large extent what the syntax of most @-rules is.
We get a lot of benefit from this. The less built-in knowledge Sass has about CSS, the less likely it is to work poorly with new CSS features. Imagine having to file a feature request every time you want to use a new CSS property—that would suck! Instead, older versions of Sass will happily keep working unless the actual syntax changes, which is much rarer.
Because of this decoupling, we’ve never needed to worry much about browser compatibility. Sass just passes whatever CSS its given on through. It’s up to the user to determine what works where, which gives them…