To add to Chris's excellent explanation, and answer your other question: no, Haml will not be getting a new syntax. The reason Sass is and Haml isn't might give you some insight into the reasons for this change. The point of Haml has always been to provide a nicer syntax for HTML, to reduce the verbosity and repetition that come with all those angle brackets and closing tags. When Sass was originally conceived, it was designed to do the same for CSS: get rid of the syntactic cruft, and make it quicker to write.
But as Sass has grown up, it's grown out of that role and into others. Especially with the aid of Compass, Sass now allows you to write CSS not just with better syntax, but with better semantics. The use of mixins, variables, and the powerful features built around those in Sass means that it's now more than just an alternate syntax for CSS. It's a language that's in many ways more powerful than CSS. And for many people, that's a very welcome thing. So I would say that the introduction of SCSS isn't just for audience, at least not in the strictest sense. It's also a recognition of what Sass has become, and a movement to support that, even for people who don't like the indented syntax. Of course, as Chris said, the indented syntax as a syntactic improvement to CSS is still valuable for many people like you (and us as well: Chris and I both prefer the indented syntax for our own use). It will always exist, and I hope you'll continue to use and enjoy it. On Mon, Apr 12, 2010 at 3:17 PM, Chris Eppstein <[email protected]> wrote: > I think you've misunderstood the direction of this project even though I > think we've been quite clear. The whitespace aware syntax is not going away. > (dramatic pause) > In Sass 3, Nathan has made the core of what Sass is a lot more technically > robust. This has allowed us to get rid of a number of syntactic annoyances > like the need to use = or #{} in the most common cases to use SassScript. > On top of this core, there are three parsers, one for the indentation based > syntax, another for the css superset syntax called scss, and one for parsing > css3. The way these parsers work is by translating your document into a > syntax agnostic representation called an AST, which can then be converted to > css, sass, or scss. This is also what enables the two syntaxes to completely > interoperate across imports. > You do not have to use SCSS to write your stylesheets and again, we have no > intention of deprecating the indentation based syntax. > (dramatic pause) > Regarding the use of $ as a variable indicator, I'm sorry that you do not > like this change, but it is one that is important to make and make > consistent across the syntaxes. The reason for this is quite simple: ! has a > CSS meaning already. It is a statement modifier. As such, that syntax is now > used to modify variable assignments: $foo: 2px !default, instead of the more > ruby-esque $foo ||= 2px. To goal of such changes is to lower the cognitive > distance between sass/scss and css -- especially for designers. > Now, regarding compass, I have decided to change the syntax of the files in > compass because I want as many people to read and understand them as > possible. You can import them into your project's sass files by simply > removing the ".sass" from the end of your imports (note: I've also converted > underscores to dashes in the import names as indicated by the deprecation > warnings in rc2). SCSS will also be the default syntax for new compass > projects, but a simple config setting and/or command line switch puts you > right back into Sass-land. > Now, regarding your statement that this is "just for adoption". Make no > mistake: that is the goal. I don't see why we would lose you as a user given > what I've said above, and we'll do what we can to avoid that, but if it > happens, it happens -- I can't make you use our code or upgrade. But allow > me to explain what is in it for you by growing the Sass community: There is > strength in numbers. We can share our code with each other, have an easier > time hiring, and an easier time convincing our management to let us use this > technology. We will learn and develop best practices by collaborating with > each other. So yes, I want to increase adoption because the power of sass is > much less about how it looks and a lot more about how the features it > provides changes the way we approach building design. > Chris > On Mon, Apr 12, 2010 at 2:09 PM, NathanD <[email protected]> wrote: >> >> I'm not sure where to post this. Ever since learning that SASS is >> going to be SCSS I've become a little distraught. I've been >> absolutely loving SASS as a language. It's visually easy to navigate >> and see how CSS cascades. It's actually a lot of *fun*, I feel like >> I'm programming Python instead of Perl/PHP. This is a good thing. >> >> With SCSS, I feel like SASS taking a step backward and getting into >> Perl territory. CSS is already dense enough. I don't really need >> curly-braces, dollar marks or semi-colons. They're just visual cruft >> that (seem to) serve no purpose but to ease adoption by people who are >> already familiar with CSS. The trade-off doesn't seem like it's worth >> it. >> >> I'm wondering if the already-wonderful HAML is going to take the same >> steps and get into using angle brackets and 'dumb it down' so that >> people who know HTML will be more at home with it. >> >> Is all this just for greater adoption? Or is there a deeper purpose? >> If it's just adoption, you've lost me. I use [compass] every day to >> style documents at work. If SCSS becomes the default to compile >> against, I'll just not upgrade. It's just not worth it to me. >> >> Thanks. >> >> -- >> 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. >> > > -- > 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. > -- 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.
