Questions about a few Sass quirks

[jhurstus]

Hello everybody. I've been working on a Java implementation of the
Sass compiler for the last few weeks (using ANTLR). For the most part
development has gone swimmingly, but I've run into a few issues with
the Ruby Sass compiler and wanted to ascertain from the community
whether these issues fall in the category of "needs to be fixed,"
"functioning as designed," or "meh . . . we may get to it sometime."

Before I go on to my laundry list, I should mention that I have very
much enjoyed using the Sass language and am thankful to all the
contributors. I'm currently working as a front end developer for a
large corporation, and using Sass has greatly improved the quality of
our (formerly highly repetitive and fragile) CSS code bases.

Also, the noted Java compiler will be released under an open source
license. I'll probably post a few more announcements/questions to the
list about that in the near future...

Onto the questions and observations about the Sass compiler. A lot of
the issues have to do with attribute selectors, which aren't in much
use now due to IE6, but I imagine will see increasing use as that
browser's market share decreases. My reference implementation for
this exercise was the version of Sass that Hampton uploaded to Github
a while back.

### 1 ###
Sass mis-lexes this css selector as a declaration (and throws an
error)

p[title="Colon: followedByWhiteSpace"]
:color red

### 2 ###
Color shortcuts in string literals can be a bit of a surprise

p
:foobar = i have a red bicycle
---
p { foobar: i have a #ff0000 bicyble }

### 3 ###
Improperly splits attribute selectors with commas

.foo
div[title="some,value"]
:color #f00
---
.foo div[title="some, .foo value"] { color: #f00; }

### 4 ###
Improperly substitutes parent selector
.baaz
.foo[title="&"]
:color #f00
---
ought to produce
.baaz .foo[title="&"] { color: #f00 }
---
but actually produces
.foo[title=".baaz"] { color: #f00 }

### 5 ###

Comma separated selectors have bizarre indentation rules when wrapped
across multiple lines.
For all the follow examples I'd expect the output CSS to be
p div, p .foobar {
color: #f00;
}
--- ok if continued line starts at 0 column
p
div,
.foobar
:color #f00

--- silently deletes nested selector if indented same amount as
beginning of selector
p
div,
.foo
:color #f00
--- output
p {
color: #f00; }

--- throws syntax error if indented 2 spaces past beginning of
selector
p
div,
.foo
:color #f00
--- output
(sass):3: Rules can't end in commas. (Sass::SyntaxError)

### 6 ###
This isn't such a big deal but the docs and source code could be a bit
more precise with their use of CSS terminology. Specifically, what is
extensively referred to as an 'attribute' is actually called a
'declaration' in CSS. 'Attributes' in the context of CSS most often
refers to a certain category of selectors (e.g. div[title="foo"]).
Similarly, what is referred to as "attribute namespaces" should be
called "property namespaces." Lastly, what is referred to as "rule
escaping" in the Sass documentation ought to be called "selector
escaping."

### 7 ###
Developers can get away with pretty bizarre constant identifiers and
length/unit suffixes. This also isn't such a big deal, but lexing
could be a bit more efficient/simpler if things were locked down some
more. (Perhaps adopt Ruby's rules for identifiers?) As an example,
this is a legal statement in Sass:
![]@~.......FOO = 2
It creates a constant with name "![]@~.......FOO" and assigns the
value 2 to it.

### 8 ###
There are many more built-in color shortcuts in CSS (as implemented in
the major browsers) than those mapped in Sass. Sass does get all the
W3C specified ones though. See http://www.w3schools.com/css/css_colornames.asp
Papaya Whip!

### 9 ###
The adjacency operator (concatenation) requires a space between
arguments, unlike Ruby which doesn't always require a space. If
you're going for the Ruby idiom, you probably shouldn't require a
space.

Aaaaand that's it. Any feedback would be greatly appreciated.

Thanks,
-Joey Hurst

[Nathan Weizenbaum]

Hi Joey,

I'm glad you're enjoying Sass, and it's cool to see an alternative
implementation being worked on. The most up-to-date implementation is
at http://github.com/nex3/haml, so check that out.

Issues 1, 3, and 4 are due to Sass not attempting to fully parse CSS
selectors. At some point enough processing will be done to handle the
cases you brought up, so you can safely implement your expected
behavior there.

> ### 2 ###
> Color shortcuts in string literals can be a bit of a surprise
>
> p
>  :foobar = i have a red bicycle
> ---
> p { foobar: i have a #ff0000 bicyble }

Implicit strings have been deprecated. SassScript now requires all
strings to have quotes around them (unquoted strings will work, but
throw deprecation errors). This is in part to get rid of confusing
cases like this one.

Both examples are expected. The second example recognizes a "div, foo"
selector nested beneath "p", but there's no content nested beneath
that. The "color" property is just nested beneath "p". Since Sass
doesn't output empty selectors, it's behaving as expected.

The third example throws an error because selectors that are continued
following a comma must have future lines at the same indentation level
as the original. Sass sees the example as nesting ".foo" beneath
"div,", and throws an error since "div," is an invalid rule.

> ### 6 ###
> This isn't such a big deal but the docs and source code could be a bit
> more precise with their use of CSS terminology.  Specifically, what is
> extensively referred to as an 'attribute' is actually called a
> 'declaration' in CSS. 'Attributes' in the context of CSS most often
> refers to a certain category of selectors (e.g. div[title="foo"]).
> Similarly, what is referred to as "attribute namespaces" should be
> called "property namespaces."  Lastly, what is referred to as "rule
> escaping" in the Sass documentation ought to be called "selector
> escaping."

This is something we should fix. Thanks for bringing it to our attention.

> ### 7 ###
> Developers can get away with pretty bizarre constant identifiers and
> length/unit suffixes.  This also isn't such a big deal, but lexing
> could be a bit more efficient/simpler if things were locked down some
> more.  (Perhaps adopt Ruby's rules for identifiers?)  As an example,
> this is a legal statement in Sass:
> ![]@~.......FOO = 2
> It creates a constant with name "![]@~.......FOO" and assigns the
> value 2 to it.

For Sass 2.2, variable names will be restricted to Ruby's allowable
symbol names; that is, symbols matching [a-zA-Z_][a-zA-Z0-9_]*.
Sensible support for international text will need to be added at some
point.

> ### 8 ###
> There are many more built-in color shortcuts in CSS (as implemented in
> the major browsers) than those mapped in Sass.  Sass does get all the
> W3C specified ones though.  See http://www.w3schools.com/css/css_colornames.asp
> Papaya Whip!

I think we're going to stick with the W3C here.

> ### 9 ###
> The adjacency operator (concatenation) requires a space between
> arguments, unlike Ruby which doesn't always require a space.  If
> you're going for the Ruby idiom, you probably shouldn't require a
> space.

This is in SassScript? I don't believe Ruby has a similar
concatenation operator... in any case, the parsing of SassScript has
been completely overhauled for Sass 2.2 and now does not require
whitespace where it's not necessary to distinguish separate tokens.

[Chris Eppstein]

Hi Joey,

While I think a Java port of Sass is cool and interesting, I would point out that it is not a prerequisite to using Sass in a Java-based web app. Ruby is only a build-time dependency and you can use the Compass command line tool (http://github.com/chriseppstein/compass/) to compile whole directories of sass into css. I've had reports of people using compass to bring sass to Django, .Net, Java, Wordpress, to name just a few environments.

Chris

[Rhett Sutphin]

Hi,

Not to pile on, but I've got another alternative to porting Sass:
Johaml is a bridge library which directly uses the haml gem via JRuby.

http://github.com/rsutphin/johaml/tree/master

It's incomplete (in particular, the J2EE adapters don't support
caching and the haml bridge only works with compiled JSP tags) and has
limited documentation (which is why I hadn't announced it before), but
the sass bridge works fine.

Rhett

[jhurstus]

Thanks everybody for all the great replies. Very helpful!

Nathan,
Thanks for the detailed responses. To answer your one question, Ruby
does indeed have an adjacency operator. For example:
irb(main):001:0> "foo" "bar"
=> "foobar"
irb(main):002:0> "baaz""quux"
=> "baazquux"
The version of Sass I'm using supports a similar mechanism (and it's
mentioned in the docs on Hampton's web site).

Chris,
Yep, I'm doing this mostly for my own education (learning ANTLR).

Rhett,
I actually wrote something very similar to what you linked at my job
(JRuby + Haml/Sass gem + J2EE filters and servlets). It's working ok,
but takes about 5 to 10 seconds to compile some of our large Sass code
bases to CSS, which can be annoying for development (it caches the
output, so it's not a concern for production). Have you had similar
performance issues? I think the source of the slow down in my case
was JRuby + JVM 1.4. Performance is quite a bit better on JVM 1.6,
but a lot of our products are still running 1.4. I've been using
CRuby privately to speed things up at development time for myself, but
would like to keep everything in the Java stack if possible, hence my
project...

-Joey

[Nathan Weizenbaum]

> Thanks for the detailed responses.  To answer your one question, Ruby
> does indeed have an adjacency operator.  For example:
> irb(main):001:0> "foo" "bar"
> => "foobar"
> irb(main):002:0> "baaz""quux"
> => "baazquux"
> The version of Sass I'm using supports a similar mechanism (and it's
> mentioned in the docs on Hampton's web site).

Huh, so it does. I could have sworn it didn't when I tested it before.
In any case, the space isn't required in 2.2.

> Rhett,
> I actually wrote something very similar to what you linked at my job
> (JRuby + Haml/Sass gem + J2EE filters and servlets).  It's working ok,
> but takes about 5 to 10 seconds to compile some of our large Sass code
> bases to CSS, which can be annoying for development (it caches the
> output, so it's not a concern for production).  Have you had similar
> performance issues?  I think the source of the slow down in my case
> was JRuby + JVM 1.4.  Performance is quite a bit better on JVM 1.6,
> but a lot of our products are still running 1.4.  I've been using
> CRuby privately to speed things up at development time for myself, but
> would like to keep everything in the Java stack if possible, hence my
> project...

After 2.2 is out, we're going to start working on improving
performance significantly.