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 https://sass-compatibility.github.io, 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.
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.
First, LibSass 3.1 should be released soon fixing a lot of inconsistencies with Ruby Sass 3.4, for instance:
transparentnot being recognized as a color (libsass#700);
rebeccapurplenot being recognized as a color (libsass#699);
ornot being reserved function names (libsass#713);
@errornot being supported (libsass#704);
@forloops not working (libsass#703);
feature-existsnot being supported (libsass#702);
inspectfunction not being supported (libsass#701);
randomfunction not being supported (libsass#657);
unique-idfunction not being supported (libsass#636);
- maps with quoted keys not able to be used as variable arguments (libsass#721);
nullable 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.
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
@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.
Non-binary accessibility & diversity advocate @n26, author, speaker. They/them.
The Principles of Beautiful Web Design, 4th Edition
Learn PHP in One Day and Learn It Well
Docker for Web Developers