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.
> ### 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)
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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Haml" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---
