OK, I've put up a Wiki page[1] to discuss all of these changes. I
think I've put a summary of all the proposals brought up so far; if
anyone sees something missing, go ahead and edit it. Feel free to add
discussions inline (I think that's better than the discuss page for
this).
Michael
[1] http://wiki.yesodweb.com/Hamlet%200.7%20changes
On Fri, Dec 31, 2010 at 9:18 AM, 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