It’s been more than half a year since the release of Haml and Sass 2.2, and a lot of work has been going on in preparation for the new version. A lot has changed in these past few months, too: there’s been an explosion of interest in Sass and other CSS compilers, a huge amount of work has been put into Compass, and the community is generally abuzz with ideas and excitement.

Because of this surge of energy, the goals for the next version of Sass have shifted dramatically. When we released version 2.2, we were expecting the biggest addition to version 2.4 to be some output-optimization features. Now those have been pushed to a later release in favor of much more major improvements. I’ve talked about some of these improvements already, such as a much more powerful way of dealing with colors and auto-compilation of CSS files. And there are even bigger, more exciting ones in the works.

Since we’re making such huge changes – ones that will in some ways reshape the face of Sass - a minor change from 2.2 to 2.4 feels inadequate. Thus, the next release of Sass will be version 3.0.

Update: After this post was written, Sass 2.4 was renumbered to Sass 3. The title and text have been updated accordingly.

One area we’re continually focusing on in Sass development is making it easier to use Sass without Ruby. Especially since Sass now supports Rack, Ruby frameworks have excellent support for Sass. But if you’re using it with another language, it hasn’t always been so smooth. That’s why we’re introducing the ability to auto-compile Sass files whenever they change using nothing more than the command-line interface.

This is the second post in my series on new features in the upcoming Sass 3. The first post described new powerful functions for manipulating colors. All these features are available right now in the haml-edge gem.

Update: After this post was written, Sass 2.4 was renumbered to Sass 3. The title and text have been updated accordingly.

There’s a lot of exciting stuff coming down the pipeline for Sass 3¹. I want to keep folks up-to-date on what they have to look forward to, so I’m starting a series of blog posts detailing the new features I’ve been working on.

New Color Functions

I’ve just released Haml and Sass 2.2.14. There are a bunch of useful changes in there; a few bug fixes, a few very minor feature additions. But there’s one feature in particular that’s more exciting than the rest: Sass now has native support for all Rack-based frameworks.

require 'sass/plugin/rack'
use Sass::Plugin::Rack

The Sass Rack plugin works just like the Rails and Merb plugins. Every request, it looks for Sass files in public/stylesheets/sass and compiles them to CSS files in public/stylesheets if necessary. These paths can be configured like so:

Sass::Plugin.options[:css_location] = "./stylesheets" 
Sass::Plugin.options[:template_location] = "./sass"

I realized today that I haven’t released Haml performance numbers in a while. In particular, there are no numbers out there for the Haml 2.2 release. This is reasonably important, since 2.2 increases performance pretty dramatically over 2.0, which was the version last benchmarked.

I’m also taking a statistics course, so you guys get fancy confidence intervals and such. So, without further ado, according to my benchmarks: Haml 2.2 without :ugly is 2.803 ± 0.036 times slower than ERB, or 1.018 ± 0.0124 slower with the :ugly option enabled. In addition, Haml 2.2 is 2.853 ± 0.029 times slower than Erubis, or 1.037 ± 0.010 times slower with the :ugly option enabled. And, because I have the data, ERB is 1.021 ± 0.0148 times slower than Erubis.

I’ve also got statistics for the master branch, which has a few optimizations for non-:ugly mode that aren’t present in 2.2. Haml master without :ugly is 2.665 ± 0.034 times slower than ERB.

2.2.5 will support it, too, as long as you’ve installed the plugin. All strings that are printed to a template will be HTML-escaped by default - if you have a string that’s known to be safe, you’ll need to manually mark it as such. This will make it much harder to make the kind of mistakes that allow XSS vulnerabilities into your app.

Haml’s supported a similar sort of XSS protection since version 2.0. If the :escape_html option is set to true, all strings are HTML-escaped by default. Special syntax is then used to insert raw HTML into the document. This option is generally not enabled by default in order to preserve backwards compatibility and to be consistent with what the user expects.

Haml versions 2.2.9 and onward support Rails’ XSS protection. This means that if you’ve got XSS protection enabled (either you’re running 2.2.5+ with the plugin, or you’re running 3.0 without the disabling plugin), Haml will escape everything by default just like ERB. It does this by enabling :escape_html, which means that you can still use the unescaping syntax to insert a raw string.