L

Early impressions on sass

March 9th 2010 02:27:02

-2

Spent a little time with "Syntactically Awesome StyleSheets" tonight (sass). I wrote up a preliminary new design for this blog, and used all of the features in the sass tutorial. My impressions as I went through this process:

  • no virtualenv for ruby afaik :(
  • debian's haml is outdated, and sudo gem install haml doesn't seem to overwrite the /usr/bin sass
  • but installing locally was ridiculously easy and gem's output is helpful; virtualenv blows my PATH away so had to add a postactivate adding the local ruby bin path..
  • after 2 seconds realized I rely on vim's excellent CSS highlight file to not make mistakes (is it line-spacing or line-height...); this is the best sass.vim i could find
  • macros and variables are a breath of fresh air
  • nesting/indentation feels right at home
  • nesting stuff like :font (family, size) or :background(position, repeat, image) doesn't really feel right in the context of the rest of the document
  • my mind context-switches to css (or js) mode from python mode and it becomes very hard to turn off the urge to put ;'s at the end of lines
  • what's the deal with : and = for setting styles? if a sigil that has no css significance was chosen for variables, you could just interpolate by default
  • I realized that sigils and interpolation don't really feel right to me, and the =/+ syntax for macros is attractive but fairly arbitrary
  • love being able to do color and spatial arithmetic
  • I like it when I guess syntax (nesting div > h2,h3,h4 > ...) and it works

My experiment involved applying style to markup that I didn't want to touch, so some of sass' macroing became really convenient, since I couldn't rely on creating classes and spreading them about the markup to distribute common styles. Grabbing any colour palatte off COLOURlovers and naming them with variables made it really easy to swap them around during the design phase; in fact, this probably saved me a lot of time. I wish they were available for use in firebug somehow.

As a non-ruby programmer, I can definitely feel the ruby heritage in sass. For one, it does make your CSS a lot cleaner looking. I have a real soft spot for this almost zen-like focus on beauty and self improvement I perceive in some of the ruby community's major projects. When I released django-selector last night, one of the first reactions was "What's the point?", and my first thought was (innocently) "a ruby developer would see the point."

The dark side of its ruby heritage is in its liberal use of sigils and in particular its bizarre sigil design choices. For instance, you can specify attribute families, like background-color, background-position, etc. like this:

h1
  :background
    color: #fff
    position: top left
    repeat: repeat-x

This seems okay at first (though it overloads the meaning of that nesting), but then you discover that when you want to nest CSS pseudo-classes (like a:hover or a:visited), you have to add another sigil:

a
  color: blue
  &:hover
    background-color: #eee

I can't help but wonder if the 'attribute family' sigil had been chosen as & instead of :, wouldn't you be able to use the much-more natural :hover syntax without an explicit sigil? The decision to make ! the variable sigil is also an unfortunate choice, although as far as sigils go I think it's the most attractive I've seen. If it had been something else ($ perhaps), it wouldn't overlap with vanilla CSS values like !important, and you wouldn't need to differentiate between : and = or have explicit interpolation (except perhaps to group for arithmetic).

comments

Chris Eppstein 00:09 March 11th

Thanks, this was thoughtful post.

I'm commenting to let you know of some of the developments for Sass3:

First, the distinction between = and : for property values is going away, in all cases you'll be able to just use the colon even if using script expressions with compound attributes

Second, variables will use $ as a sigil instead of ! which avoids the confusion with existing syntax and "not".

& stands for the parent selector in any nested context and without it, a simple selector like :hover would end up as ".foo :hover" instead of ".foo:hover" because nesting always joins with a space unless & is present.

In our new syntax called scss that is being added which is a CSS superset, we don't use = and + for mixins but instead the directives @mixin and @include.

We'd like to add support for ; in the Sass syntax. this would also allow one-lining.

Anyways, I'd say you identified most of the Sass warts... we're working to address them in sass 3.

Jason Moiron 02:13 March 11th

@Chris

I'm afraid I don't quite get what is happening in the example where you have:

div
  :background
    color: white
    image: url("/foo.png")

This doesn't become div :background color, does it? If the & was used for this construct (and left off the :hover style cases), wouldn't you be able to recognize all : classes and join appropriately?

Anyway, the improvements sound like they clear up all the niggles I came across. Love the idea of using @mixin. The next release is going to be a fantastic improvement; I'll be watching closely! Thank's for your work on sass :)

+ leave a comment on "Early impressions on sass"