The Indented Sass Syntax is Here to Stay

Posted May 12, 2010

Although Sass 3 (which was released on Monday) introduces a new CSS-extension syntax for Sass, the indented syntax will continue to be fully supported. There continues to be confusion about this, so I’ll repeat: the Sass indented syntax has not been and will never be deprecated.

The reason SCSS exists is to provide people who liked the syntax of CSS with the power offered by Sass. However, we recognize that a large part of the initial popularity of Sass is due to the fact that some people don’t like the syntax of CSS. We want to support those people and so we will continue to support and evolve the syntax they prefer.

To help drive the point home, especially to people who don’t read this blog, I’ve tweaked the Sass homepage a little. Now all the examples are presented in both SCSS and Sass, and there’s a tab interface for picking which format you’d like to see.

I hope this puts to rest some of the worries Sass-lovers had that their syntax was going away.

Andy said May 12, 2010:

Nathan, you should update in that way the examples in http://github.com/nex3/haml ’s Readme too.

Michael Teter said May 28, 2010:

This may be overkill, but I’d even put a little * footnote on the main page in the “The second, older syntax” paragraph.

For people like me who have just now come upon Sass (and having just arrived from Haml), the immediate appeal is definitely both the brevity and the similar format to Haml. But without a footnote or other notice beyond “sass will continue to be supported”, I was inclined to assume the old syntax would eventually be phased out.

Sonja said May 30, 2010:

When you use adjectives like “new, main” and “old” to describe the two syntaxes, it implies that one is the future and recommended, and the other is becoming obsolete.

Maybe you should remove those adjectives and simply present them as “Sassy CSS” and “(indented) Sass” if you want to give them equal importance and let users pick the one they prefer.

Nathan said May 30, 2010:

The problem is that I need to strike a balance between explaining that there are two syntaxes, explaining why one of them is presented in preference to the other, and explaining that the older syntax will still be supported. I’ve tried modifying the Sass page to do this a little better; let me know what you think.

Doug said May 31, 2010:

I would have come to the same conclusion as sonja.

In the post its implied that the only difference between scss and sass is syntax. “The reason SCSS exists is to provide people who liked the syntax of CSS with the power offered by Sass.” Does this mean that the ONLY difference between the two is the syntax and that you can accomplish the same functionality in both? This is an important part of the decision making process. I prefer the sass syntax but if for some reason it is inferior to scss that should be made clear and what the limitations are from one to the next. While I appreciate terseness in my css I would prefer verbosity in the details and reasoning for this change otherwise it will be difficult to know what the right choice is for me. Thanks.

Nathan said May 31, 2010:

Both syntaxes do indeed have the same expressive power. I thought that was implied by calling them “syntaxes”... do you have a suggestion for clarifying the point?

Dan said June 01, 2010:

I am new to saas and I prefer Sass over SCSS. Before reading the blog I assumed I should use SCSS since it’s the ‘new thing’ and even the tutorial is about SCSS and not Sass.

Nathan said June 01, 2010:

The recommended path at this point is to learn SCSS first, and then switch to Sass if you want to. This does make it a little more difficult for folks like you, Dan, and I’m sorry about that. However, I think the effort required to maintain two separate sets of documentation, not to mention to make both of them easily discoverable without hurting the usability of the Sass website, is prohibitive.

Martin said June 10, 2010:

I guess the semicolons and brackets syntax is here only for those used to traditional CSS, but for me indenting is so much better. I’d like to see opinion of experienced people, who prefer semicolons and brackets and a good reason for using it.

Gustavo Delfino said June 14, 2010:

Is there a way to configure SASS (being used in Rails) to use the indented syntax by default?

Steve Leung said June 26, 2010:

I am the author of a site with 15 million hits a month and I use sass because I was attracted to the indented syntax terseness. I would definitely recommend a note explaining that sass is not inferior to scss in any way. Calling them ‘new’ and ‘old’ syntax implies that one will be deprecated and I was about to abandon sass completely until I saw this post.

Sass really is great – it’s what’s awesome about it. It has ‘syntactical sugar’. I would strongly urge you to make it the preferred syntax.

Screwlewse said June 30, 2010:

Very funny.. didn’t I just ask you about this at the meetup? Sorry, I shoulda been reading your blog. :D

Yaroslav said July 03, 2010:

+1 for a clearer explanation of the equivalence, both in importance, future proof and power of the two syntaxes. I am new to rails et al, and was disappointed when reading the (new!) home page at http://sass-lang.com/. Well at least until I came to this blog post. Not all potential users are going to read this post, though.

Maybe you should listen to all of the above commentators, remove the ‘new’ and ‘old’ adjectives from the text and make it clear the the two syntaxes are equal alternatives.

KingCode said July 06, 2010:

I just came to, and love Sass and consider it a tool I won’t be able to do without. I really like the website and tabs making obvious that both sass and scss pack the ‘full punch’.

As an aside, I found an extra reason not seen discussed here, for using scss over sass, even though I much prefer sass: the brackets are more robust than indentation.

I recently found myself having to copy paste some converted HTML-to-HAML page fragments into my own HAML code, only to see the parser choke over the different whitespace formats used by the converter vs. my code, and ended up having to edit the whole thing by hand, one line at a time.

So if the .sass parser is prone to fussyness, it might be a good idea to point out the obvious advantage of using .scss files when merging Sass code. If there is another trick such as a command option (and other than Regexp editing) for merging .sass or .haml files I’d love to know about it.

Jimy said August 30, 2010:

It’s good to have both syntaxes. I prefer the syntax with the brackets, but that might be because I come from a programmer’s background, but it feels more structured to me then just using indentation (a reason why i never got used to python either, i guess).

For those asking if there is a benefit: One obvious benefit of using SCSS over Sass syntax is that you can just take an existing CSS file and it’s instantly compatible and can be modified from this point, without having to rewrite it first to Sass syntax. So that’s really a great addition!

Jethro Larson said September 14, 2010:

Where y’all go? No posts since may?

Nathan said September 14, 2010:

Jethro: I’m still around. After the massive push towards the Sass 3 release, I decided to take it easy for the summer and focus on settling into my new job, so until recently I’ve been keeping my Sass involvement at maintenance levels. However, we’ve started ramping up towards a new release, so expect to see some new blog posts soon.

Renato Carvalho said December 02, 2010:

Thanks for continue supporting the original/old Sass syntax. I’m used to work with Sass from long time now. This week I tried to work with Scss. Just impossible for me :)

The original syntax is much simpler to work and the code is much cleaner.

Cheers mate. Thank you for all the hard work!

Paul said February 22, 2011:

Speaking as a new user, having the two syntaxes makes learning Sass and frameworks that use Sass a lot trickier. Where it really hurt me was when trying to learn Compass. The documentation is a mess. e.g. sometimes it uses the ”+” sometimes it uses the ”@include”. It also hurts when you come from a third-party tutorial (e.g. the ThinkVitamin screencasts).

As much as you may like the dual syntaxes,or want to not tick off a particular userbase, it is very off-putting to new users. The problem doesn’t mainly affect experienced users of Sass, but rather third parties like tool makers and tutorial writers.

John said May 20, 2011:

I second the point Paul mentions. The Compass website does have a SCSS/SASS switch in the top right corner of the page but on most pages I tried it just does nothing. The Susy-Plugin for Compass only supports SCSS. And I do understand that. Maintaining two versions of every tool and every documentation and every tutorial and every blogpost regarding SASS is just too much to ask for. I will try to stick with the “old” syntax as long as I can. I came to SASS because the syntax was different and better than CSS. I wouldn’t want HAML to be more like HTML either or Ruby to be more like PHP. I feel SCSS is a major step in the wrong direction. Thanks anyway for your work, Nathan.

Stu said July 02, 2011:

Hello, I’m a first time user who just discovered SASS via a blog using the white space syntax. Since my first impression on this topic is still 30min fresh, I thought I’d share my experience.

My initial misunderstanding came from the title of the homepage juxtaposed with the .scss extension. It was confusing to me until I realized that .scss and .sass files are both SASS, whereas up until that point I had thought that the name SASS by implication only described .sass files and that .scss files must be related, but how I could not say exactly.

When I started reading the tutorial I thought there must be some kind of mistake because it seemed illogical that a less legible more obfuscated syntax dependent on braces would usurp the clearer more efficient version already in existence. Of course things made more since when I realized you were providing the braces as a transitionary stage for the benefit for those used to the more CSS like style of doing things.

If I had any suggestion I would say ditch either .scss or .sass and combine them both into just one file extension. Then you could use something like a shebang in the head of the file to declare your syntax preference, e.g., #!whitespace.

On the home page tutorial you could first introduce people to the language with the braces-based syntax. You could then end the tutorial by revealing the white space based version as the purest most ideal form of the language. I think that would help stem the confusion introduced by the current side by side format currently in place.

Of course my suggestion may be completely impractical, still, thought I would throw in my 2 cents. Regardless of what you choose to do, you really have created something great here!

Dom said September 16, 2011:

I’m having exactly the same experience as Stu with SASS and COMPASS and I 100% agree with his comment. “Opinionated software” ! Don’t let the user choose.

Benxamin said October 23, 2011:

Funny, we’ve been calling them “common” and “HAML” at work. I love that you can convert damn near any form of CSS into the .scss file type. That’s a huge piece of flexibility that CSS was missing. That being said, I still prefer the SASS style. I can’t stand working with brackets anymore.

Make your comments snazzy with Textile!