Introducing Sass-Compatibility

Originally published at: http://www.sitepoint.com/introducing-sass-compatibility/

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.

Continue reading this article on SitePoint

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 caniuse.com 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

https://github.com/sass/libsass/issues/697, https://github.com/sass/libsass/releases

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.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.