Eric, If it's just the variables, I can deal with $. I write PHP all day. Part of my frustration with the SCSS syntax stems from that :)
Thank you all for the clarification. I spend a lot of time knee-deep in PHP/HTML, CSS and JS and anything to make even part of my life easier is great. Things that make my life harder end up trashed. *cough* IIS *cough*. I've already impressed some of my co-workers with some of the mixins and color functions. Hell, I've impressed *myself* with that stuff. On Apr 12, 9:41 pm, Eric Meyer <[email protected]> wrote: > 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.
