Hacker News Reader

Comment by djacobs | Hacker News Reader

I'm very happy that SASS and HAML are finally separated, and I don't think I'm alone in that. But I'm not a fan of this mini-language that's gradually creeping into SASS.

I do understand the need for SASS not simply to be a declarative language. (Its dynamic nature is why I started using it in the first place.) However, growing a language ad-hoc around CSS doesn't seem like the best way to go. Instead, I would recommend preprocessing SASS through an existing interpreter (like a Ruby implementation) and not come up with language features "on the fly".

Long-term, it's clear to me that CSS would be much more useful if it were written in a homoiconic Turing-complete language. That way, we could code configuration succinctly (via macros) but have access to all the power of the full language when necessary.

What I'm saying is: right now this feels like a hack.

View on HN

At the same time, user-defined functions solves a big pain-point with SASS at the moment. The older style of SASS functions were a very limited form of macros. They're useful for a lot of things, like applying a generic button style to a bunch of different elements, but aren't able to, for example, make a standardized syntax for gradients which generates the appropriate code for FF/Webkit/IE.

Previously to accomplish that sort of thing you'd have to use the Ruby API, as Compass does. Now you can do it entirely inside .sass files. This seems like a clear win, and will definitely simplify my stylesheets.

There's no "gradual creeping" or "ad-hoc" language features being added "on the fly". We spend a lot of time thinking about what features are included in Sass and most feature concepts do not get added.

Feel free to write your CSS in ruby, it would take less than a week to whip up a DSL for CSS, but good luck trying to get a designer to use it ;)

Don't get me wrong, I'm a huge fan of SASS and Compass and think variables have been implemented well. But retroactively adding functions feels ad-hoc, even if great care was taken when adding the feature. I feel that designers might be more likely to write Ruby methods than these style functions (though of course I don't have data to back that up).

I wrote a library to do something like this a couple of years ago. Not sure if it's exactly what you need, and it could probably do with a lick of paint, but you might find it interesting.

http://beastaugh.github.com/stylish/

I like this idea.

With Ruby 1.9, you have a range of ways to paint over the syntax, like you allude to:

  Stylish.generate do
    rule "div.section" do
      p line_height: 1.5
      a text_transform: 'uppercase'
    end
  end

Interestingly, you could go further and make this almost look like CSS:

  Stylish.generate do
    rule "div.section" {
      p { line_height: 1.5 }
      a { text_transform: 'uppercase' }
    }
  end

(To do this, you'd have to let the p and a methods to accept blocks. For anyone who doesn't know, the interpreter will bind blocks instead of treating the braces as a hash parameter if you omit the parens.)

You could even make the HTML elements (like div) into objects and use some #method_missing magic to allow the following:

  Stylish.generate {
    div.section {
      p { line_height: 1.5 }
      a { text_transform: 'uppercase' }
    }
  }

So yeah, I like the library a lot. Ruby has some interesting possibilities in this space. (Then again, so does Lisp.)

> To do this, you'd have to let the p and a methods to accept blocks.

They do—the problem is that blocks are used to express nesting. One could probably rewrite the interpreter to do what you suggest without too much of a headache.

> Ruby has some interesting possibilities in this space. (Then again, so does Lisp.)

If I were to write it again, I would be very tempted to use Lisp instead. The syntax wouldn't be as close to CSS as Ruby, but it would make it a lot easier and more natural to perform transformations on trees of rules.

Ultimately a decision whether to use a library like this is dictated by two factors: will the person writing the frontend code be happy using (and, presumably, debugging and patching) a library of this sort, and is the gain in expressivity sufficient to overcome the need to write it in the first place and then familiarise the users with it? As discussion elsewhere on this thread indicates, I suspect that most of the time the answer will be 'No'.

There are two reasons for this. Firstly, even if the sort of frontend developers who write lots of CSS are, in general, at least some sort of programmer, it's rare that they will be the sort to quickly become comfortable writing in Lisp. Secondly, while the gains in expressivity and maintainability when one can factor out repetition and introduce variables are important, presentation-layer code does not lend itself to the kind of reduction in size (by introducing abstractions) that application-level code is. It's hard to write very general CSS; one tends to quickly become bogged down in special cases.

Reply on news.ycombinator.com