Nathan, Not only is it optional, but I just discovered it is entirely hidden from you unless you go looking for it. I am also a fan of the old syntax, but wanting Susy to stay in line with compass, I spent today making the switch for susy (to be released in mere hours if all goes well).
When I created a new compass/susy project I entirely expected that the template files (_base.scss etc) created by susy would be all scss-y and frustrating to look at. Not bad, considering I could just sass- convert them, but annoying for those of us using the old syntax. But that Didn't Happen! Whoever built this thing built it right: the conversion happened automatically and behind the scenes based on my "preferred_syntax" setting in config.rb. As far as my project goes, Compass and Susy are still exactly the same as they ever were. Nothing Has Changed. Fantastic. (well, ! changed to $, but that's an unrelated update: I didn't have to look at any scss anywhere.) This update, for everything happening in the back-end, is slick as hell as far as syntax choice goes. Cheers, -e On Apr 12, 7:29 pm, NathanD <[email protected]> wrote: > I'm glad to hear that the new syntax is optional. I nearly had a > heart attack when I saw the change. > > Sorry about the rant then. Keep up the good work, and I hope to > continue using SASS/Compass for a long time! > > On Apr 12, 6:36 pm, Nathan Weizenbaum <[email protected]> wrote: > > > 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.
