[web-devel] Hamlet variable interpolation syntax [previously: A few questions about Yesod]

[Aur Saraf]

While we're on the topic of breaking changes to Cassius:

This week I've heard a lecture about Sass[1] and Less[2].
[1] http://sass-lang.com/
[2] http://lesscss.org/


This is Sass:

#navbar {
  $navbar-width: 800px;
  $items: 5;
  $navbar-color: #ce4dd6;

  width: $navbar-width;
  border-bottom: 2px solid $navbar-color;

  li {
    float: left;
    width: $navbar-width/$items - 10px;

    background-color:
      lighten($navbar-color, 20%);
    &:hover {
      background-color:
        lighten($navbar-color, 10%);
    }
  }
}

Less is very similar.

There are a few things I've learned:

1. Sass used to have a whitespace-is-significant syntax, but then
switched to a CSS-superset syntax like Less, because it let people
port their existing CSS by... doing nothing. Remembering all the times
I've had to translate CSS to Cassius by hand, I think we should at
least have a program like Python's 2to3 that translates a block of CSS
to Cassius, if not move to the Sass syntax.

2. Sass supports some nifty features that I wished Cassius had
(inheritance and mixins, numerical and color math, mixins with
parameters which are like functions...)

3. Sass has Compass[3][4], which is sort of a standard library for
CSS, with battle-tested classes that you can mix into your CSS for
doing things you tend to do a lot and for doing things in a manner
supported as cross-browser as possible. A lot of times, when writing
CSS, I wish I'd have that. So that's another point for supporting Sass
syntax.
[3] http://compass-style.org/
[4] An example (implementation of a) Compass function:

@mixin hide-text {
  $approximate_em_value: 12px / 1em;
  $wider_than_any_screen: -9999em;
  text-indent: $wider_than_any_screen * $approximate_em_value;
  overflow: hidden;
  text-align: left; }


To support Sass syntax, we could either parse it, which is as
complicated as parsing CSS, and then reimplement Sass's logic, which
isn't very hard but would require us to chase it as it changes, or we
could use a plaintext-with-variable-interpolation parser and feed that
to the Sass toolset (without any harm to the type safety of the code,
and with options to run Sass either in compile-time or in run-time,
but it would require the user to install ruby and Sass).

Of course, Sass support could be added quite easily on a per-project
basis (and I just might do that soon for one of mine), but as I've
showed, there are some serious advantages to making it default.


 -- Aur