How Sass can shape the future of CSS

The rise in popularity of CSS extensions, such as Sass, in recent years has not gone unnoticed by the people who work on proposing and standardizing modules for CSS3 (and CSS4).

Sass Features Being Adapted for Submission

Many of the key features found in Sass are being adapted for submission to the W3C. Variables, Mixins, and Nesting are all mooted for inclusion in CSS, and we may see some of them appear in the near future.

Then again, we may not; resistance to the proposals is quite strong from certain members - for example, Bert Bos wrote a long article on why he considers CSS Variables to be harmful. But I thought it would be interesting for the Sass community to see how the software to which you develop and contribute to (Sass) is being used to discuss the future of the web.

The Variables Proposal

This proposal should look very familiar to you - it's the same syntax that Sass uses, with one addition. Each variable is defined using a three-part syntax: first you set up the declaration using the @var at-rule, then you provide a unique name with the $ character before it, then you set the value:

@var $foo #F00;

Once set up like this, you can reference your variable by using the unique name as a value:

h1 { color: $foo; }

This proposal has already been put forward to the W3C, and I'll tell you the result of that shortly.

The Mixins Proposal

As with Variables, you should be very familiar with the Mixins proposal - the syntax used in Sass was the inspiration. You create a declaration block using the @mixin at-rule, assign a unique id, and then add your rules:

@mixin foo { color: #F00; font-weight: bold; }

When you need to use that code block you call it using the @mix directive and the unique id you previously assigned:

h1 { font-size: 2em; @mix foo; }

As you can see, the only difference is that the CSS proposal uses @mix in place of Sass's @include. As with Sass, you can also use parameters with Mixins:

@mixin foo($bar #F00) {
  border-color: $bar;
  color: $bar;
}
h1 {
  @mix foo(#00F);
}

An Alternative Variables Syntax

Recently, an alternative syntax for Variables has been proposed. This syntax looks and acts somewhat similarly to the HTML data attribute, although it's not the same. In this proposal variables are scoped to elements (for global scope, you'd use the :root selector) and the variable name is prefixed with data-:

:root {
  data-foo: #F00;
}

Then you reference the variable by using the unique name in the data function:

h1 {
  color: data(foo);
}

This has the advantage of allowing scoped variables, and integrating better with the CSSOM, JavaScript, as well as inspector tools like Firebug or Dragonfly.

It must be stressed, however, that this is still only at the discussion stage.

So When Will We See Them?

As I said, maybe never. As I understand it, the first Variables proposal was not well received by the W3C - but the module author, Tab Atkins, is continuing to refine it anyway. Tab is also key to the creation of the alternative syntax. You can follow along with Tab and his writing at his personal blog where he shares his thoughts on web standards as well as details surrounding discussions on the future of CSS.

As for Mixins, they were rejected out of hand and probably won't be pursued. The reason given? Lack of use cases. But I can't imagine that you, as Sass creators, developers and users are short of use cases for Mixins. So, if you have them I'd love to read them - please leave a comment below sharing your thoughts if that's the case.

If work does continue on these proposals, or any part of them, I think that it would be a matter of little time before browsers started to implement them; I believe, in fact, that WebKit already implemented Variables, only to remove them after feedback from the W3C.

Conclusion

I have to confess that I've only briefly experimented with Sass, and have not used it in any production websites, but what I like about it is the ease with which it's been possible to adapt the syntax into CSS itself. It's great to see community-created language extensions influence the evolution of the web, and even if none of these proposals ever make it to the implementation stage, you can be sure that at the very least they form part of the standards conversation.

November 21, 2011 ~ Editorial, Peter Gasston