Sass 3 Delivers CSS Compatibility, Selector Inheritance

Posted by Paul Blair on May 07, 2010

Sections

Architecture & Design,

Development,

Enterprise Architecture

Topics

Web 2.0 ,

Ruby ,

Ruby on Rails ,

Domain Specific Languages

Tags

CSS ,

DSLs

When InfoQ last visited the Sass stylesheet language, project maintainer Nathan Weizenbaum had promised a future Sass release offering CSS-like brace syntax in addition to its own indented syntax. Haml/Sass 3 is now nearing its final release, anticipated on May 10, with the change in Sass syntax its primary feature:

There’s no question that version 3 is focused on Sass. Haml’s certainly had some love, but this release would without question have been version 2.4 if it hadn’t been for Sass. The reason for this is that Haml’s settled down.

The new Sass syntax is called SCSS (for "Sassy CSS"). SCSS is a superset of CSS3:

This means that it’s 100% compatible with CSS3: every valid CSS3 document is a valid SCSS document that means the same thing. In addition, it supports all the hacks and vendor extensions we could find, even crazy nonstandard syntax like Microsoft’s expression() function and filter property.

No change has been made to Sass' basic function of enhancing stylesheets with variables, operations, nested selectors, and mixins. The syntax change is intended to attract new users to Sass by minimizing its syntactic differences from CSS. An added benefit is to make it easier for CSS tools to support Sass.

Sass' original indented syntax will continue to be available and supported for those who wish to use it. However, one result of making SCSS compatible with CSS3 has been to deprecate certain syntactic features of Sass: the exclamation point prefix for variables (the dollar sign is now used instead) and the equals sign for assigning values (a colon is now used). The handling of rendering quoted strings has also changed.

A second major new Sass feature is the @extend directive allowing one selector to inherit all the styles of another:

There are often cases when designing a page when one class should have all the styles of another class, as well as its own specific styles. The most common way of handling this is to use both the more general class and the more specific class in the HTML.
[...]
Unfortunately, this means that we have to always remember to use [e.g.,] .error with .seriousError. This is a maintenance burden, leads to tricky bugs, and can bring non-semantic style concerns into the markup.
[...]
@extend works by inserting the extending selector (e.g. .seriousError) anywhere in the stylesheet that the extended selector (e.g. .error) appears.
[...]
xCSS... until now had the closest thing to full selector inheritance of any CSS compiler... . However, xCSS still lacks a critical component for full inheritance: .seriousError is only added when the selector is exactly .error, rather than .error.intrusion or .admin .error.

Sass 3 also introduces a utility for converting files between CSS, Sass, and SCSS, including converting from Sass 2 to Sass 3 syntax.

Sass::Plugin, which updates CSS files whenever Sass files change, will see improved performance in the new release. In addition, this auto-update functionality will now be available to the sass command-line utility via the new flag --watch.

The changes made to Haml include the generation of HTML 5 custom data attributes and the simplification of multiline syntax.

• Older >