By Hugo Giraudel

Introducing Sass-Compatibility

By Hugo Giraudel
Help us help you! You'll get a... FREE 6-Month Subscription to SitePoint Premium Plus you'll go in the draw to WIN a new Macbook SitePoint 2017 Survey Yes, let's Do this It only takes 5 min

For weeks now, I – with the help of some folks – have been collecting inconsistencies between Ruby Sass and LibSass. At first, it was nothing but a GitHub Gist but then, I made a CodePen out of it with a custom stylesheet and everything. It still was not enough, so I made a full project out of it. Let me introduce Sass-Compatibility.

The goal of Sass-Compatibility is to provide a list of inconsistencies between different Sass engines. Not only Ruby Sass and LibSass of course, but also Ruby Sass 3.2 and Ruby Sass 3.3, or Ruby Sass 3.3 and Ruby Sass 3.4.

The basic scenario is you wanting to move your code base over to LibSass but are unsure whether you can do it because of missing features. We’ve got you covered. Head to, have a tour, and check for yourself if it’s okay for you to lose some features to enjoy LibSass’ speed.

Note: on topic, be sure to give Switching from Ruby Sass to LibSass from James Steinbach a read.

Sass Compatibility Site

How does it work?

At the very start, it was mostly manual testing on SassMeister, then writing results in a table. Quite tedious, and not very scalable (especially since I had highlighted over 30 inconsistencies) so I quickly moved to a fully-automated system thanks to Valérian Galliat.

You may not know it, but there is a project called sass-spec. Sass-spec aims at providing a test suite for Sass engines to make sure they are compliant with the official Ruby version of Sass. However, we should note that the project is currently in an odd state where it has some tests for LibSass only, some old tests from Ruby Sass pre-3.0, some disabled tests… Basically, kind of a mess.

That being said, LibSass maintainers are doing a tremendous job to keep all features tested with sass-spec. That means every single code snippet that gets merged in LibSass code base has a test written in the sass-spec project.

Thanks to this, we decided to pull tests from LibSass rather than rewriting them. For inconsistencies that have no tests, either I added one to sass-spec, or I wrote one specifically for Sass-Compatibility. Ultimately, the goal would be to use only sass-spec’s tests, not my own but meanwhile we gotta do what we gotta do.

Anyway, we have a list of features with some associated tests. A feature can (should?) have several tests to make sure it is 100% covered. Then, we have a (blazingly awesome) Rakefile that iterates over all tests from all features, and run them thanks to SassMeister’s back-end. Then, it writes a support file that’s being used in the view to display everything.


What now?

First, LibSass 3.1 should be released soon fixing a lot of inconsistencies with Ruby Sass 3.4, for instance:

  • transparent not being recognized as a color (libsass#700);
  • rebeccapurple not being recognized as a color (libsass#699);
  • not, and and or not being reserved function names (libsass#713);
  • @error not being supported (libsass#704);
  • decrementing @for loops not working (libsass#703);
  • feature-exists not being supported (libsass#702);
  • inspect function not being supported (libsass#701);
  • random function not being supported (libsass#657);
  • unique-id function not being supported (libsass#636);
  • maps with quoted keys not able to be used as variable arguments (libsass#721);
  • null able to be concatenated (libsass#698).

I probably missed a lot of bug fixes and extra features, nevertheless, this should mean a lot more green blocks in the LibSass column for Sass-Compatibility. This could even lead me to remove some features once I’m sure they work in every engine.

Sass Compatibility Preview

Along the same lines, I’d like to avoid running my own tests and only use those from sass-spec. That should be doable since Michael Mifsud told me he, as well as Sass and LibSass teams, wants sass-spec to be the one test suite for all engines.

How can you contribute?

There are several things you could do to contribute to Sass-Compatibility. The best one would be to find an inconsistency between LibSass and Ruby Sass (or any other engine basically) and open an issue about it. From there, we will try to add it to the site, and report it to either Ruby Sass or LibSass so they can fix it.

Along the same lines, we always need more tests and better tests. If you think you can improve a test suite (either on sass-spec or on Sass-Compatibility’s own tests), it would be awesome if you could submit a little pull request. Some features like @extend or @at-root are quite complex to tests in their entirety, so be sure to tell us if you have found an uncovered edge case.

Also, if you find something that looks wrong to you, please be sure to get in touch so we can check what’s going on. Mistakes happen.

Anyway, I hope this project will help Sass community to move forward.


Why are there so many incompatibilities with different Sass engines? Is there an official spec? Are the developers working towards making LibSass and Ruby Sass fully compatible? This doesn't exactly give me confidence in building on top of Sass if I have to check compatibility to use Sass features. I already spend enough time on and Google checking compatibility.


Sass has been developed in Ruby at first, almost 7 years ago. Because of Ruby's slowness when it comes to compiling stylesheets, a group of people decided to create a Sass port in C called LibSass.

It has long been lagging behind the official Ruby implementation, but for the last couple of months, there has been a tremendous activity coming up regarding LibSass. In fact, LibSass and Ruby Sass teams decided to synchronise both versions before moving any further.

Now, there are a few things to know if you want to write Sass code:

  • You usually don't switch between engines, so the basic scenario is you picking either Ruby Sass latest or LibSass, then sticking to it. There is no need to check compatibility at all, unless you are planning on releasing Sass softwares like libraries and grid systems that need to work everywhere.
  • There are incompatibilities between different Ruby Sass versions: it's called releases. There is nothing that can be done about that, it's natural software development.

It seems like instead of 3.0.3, 3.1.0 will be released.

3.1.0beta is already out,


Thank you for the response, Hugo.

I am building my own grid system as part of a WordPress theme framework that I had considered open-sourcing one day. I just checked my gulp setup and it looks like I'm using Ruby Sass. It sounds like Gulp may compile faster if I switched to LibSass but I'll have to check compatibility first. This makes Sass-Compatibility a very useful bookmark for me.


It seems a detailed article. Actually i'm a bit new to the sass, just started 1 month ago and making use of @extends, inhertance etc and while learning this stuff i created an article for a guide to sass but didn't cover this kinds of compatibility as you did because i was lacking of this, Knowing this compatibility is useful to get the full features of sass. Thanks for this.

Get the most important and interesting stories in tech. Straight to your inbox, daily.Is it good?