Sass vs. SCSS: which syntax is better?

Leave a Comment

Since the creation of Sass nearly 5 years ago, it has been plagued by many levels of controversy. It billed itself as “a better CSS” and added brand new features unheard of to CSS authors such as variables, nesting and mixins. Sass also introduced an entirely different indentation-oriented syntax and a brand new perspective on how to author CSS.

The Sass syntax

The indented syntax of Sass was inherited from its first-born brother Haml. And while Sass and Haml once got along – Hey, they even shared the same Ruby Gem! – dissension in the family caused the two languages to split and go their separate ways. Each seeking its own fame and fortune in the land of Open Source opportunity.

One common objection among Sass detractors is that the indented syntax is so foreign to CSS. Why spend the time learning a language that is radically different from CSS? This difference, they fear, will make it hard for them to continue to remain fluent in a language with as many nuances and subtleties as CSS.

What if Sass is just a fad? What if it doesn’t last? What if it doesn’t gain traction among the masses? What if all their code and newly formed best practices fall by the wayside should the “downfalls” of Sass become a reality? What if … ah, you get the point.

And the objections trail on …

SCSS to the rescue!

In version 3 of Sass, the SCSS (Sassy CSS) syntax was introduced as “the new main syntax” for Sass and builds on the existing syntax of CSS. It uses brackets and semi-colons just like CSS. It doesn’t care about indentation levels or white-space.

In fact, Sass’s SCSS syntax is a superset of CSS – which means SCSS contains all the features of CSS, but has been expanded to include the features of Sass as well. In layman’s terms, any valid CSS is valid SCSS. And in the end, SCSS has the exact same features as the Sass syntax, minus the opinionated syntax.

Those who are new to Sass have less to learn. And as for Sass detractors, well, they can no longer complain about the syntax. As far as I’m concerned, SCSS is the new CSS.

Which syntax is better?

If you are an old hat at Sass, chances are you’ve got an opinion about which syntax is better. And there are a lot of good people on both sides of the aisle. Some prefer Sass, the original syntax – while others prefer SCSS. Either way, there’s no need for panic or worry because Sass’s indented syntax has not been and will never be deprecated!

I’m not even going to pretend to be unbiased in this debate. I myself am a huge fan of SCSS. A recent convert, actually. I was once a die-hard fan of the indented syntax, but I’ve changed my mind on the matter and I wrote this article to share why.

Before I get to that, let me explain the reasons I loved Sass, and why I almost didn’t give SCSS a chance.

Pros for Sass

Reason #1: The Sass syntax is more concise

It’s true. The indented syntax removes the need for semi-colons and braces. It doesn’t require that you use the verbose @include to mixin your mixins. Instead it uses the + operator which requires less typing and makes your code simpler, and easier to read.

Reason #2: The Sass syntax is easier to read

Because of its rules about indentation, it’s kind of hard to write unreadable Sass. Sass forces you to write your code the same way every time. There’s no option for venturing off and making your own style of commenting and formatting. It’s very strict on how things can be done. On large teams or in situations where you aren’t the sole author of all the code, this could be a huge plus. It forces the team into more strict coding practices (much like what XHTML did for HTML) and leaves little room for deviation from the beaten path.

Reason #3: The Sass syntax doesn’t complain about missing semi-colons

Ok, I know this probably belongs with reason #1, but I’m listing it separately because it was one of the major reasons I loved the original syntax. Not only did I not have to type semi-colons at the end of every attribute/value pair, but Sass ensured that my output always had the correct semi-colon placement. This is a huge win over writing vanilla CSS which doesn’t complain about semi-colons (but, the CSS validator does). When I wrote straight CSS I was always surprised by how many times a misplaced semi-colon was the reason a rule didn’t get applied properly.

This isn’t a points war

Now, before I get too far ahead of myself, I just want to say that this article isn’t a 3 points for Sass, 8 points for SCSS argument. Sure, I list more points for SCSS, but your feelings on each of the points are going to vary. For some, the three points I’ve stated above as pros for Sass will be persuasive enough to keep you using it. For many, switching back to something more like CSS after using Sass will seem like lunacy.

For me that’s exactly what it felt like the first time I tried to do a project in SCSS. The brackets and semi-colons were back. A lot of what I hated about CSS was back. It was like taking a step backwards instead of continuing to push forward (that’s the point right?).

In fact, like any good citizen of the Internet, I tweeted my hatred of SCSS. I had dipped my toes in the water and found it too chilly for my taste. So I hung up my curly-braces and semi-colons and went on my way. Sass was good enough for me just as it was, thank you very much. No need to revert back to the dark ages of CSS just to get a more familiar syntax.

A change of heart?

So, what changed my heart? To tell you the truth I’m not really sure. A lot of it for sure had to do with the fact that my good friend Brandon Mathis had recently made the switch to SCSS and felt it was better. Though he offered a couple of sound arguments, which I’ve reused below, Brandon really didn’t try to persuade me too much. Mainly, he just said that he had found he liked it better. It took him a while, of course, but he was much happier now that he had made the switch.

Now Brandon has probably written more Sass than almost anyone I know. He’s on the Compass core team and has been using Sass exclusively in his projects for over 4 years now. Needless to say, his opinion holds a lot of weight with me. Also, Chris Eppstein (the author of Compass) seems to prefer the SCSS syntax. He likes it so much, that he even rewrote all of Compass in it.

I was beginning to question my resolve. So on my next project, instead of giving it a half-hearted try for a day, I decided to go all in and code the whole project in SCSS to compare the difference. The outcome? I found that it took some getting used to (as expected), but I actually began to prefer the new SCSS syntax to the original Sass syntax.

Here’s why …

Pros for SCSS

Reason #1: SCSS is more expressive

No really! I know I argued above that Sass is easier to read because of the way it forces you to write your rules and attributes with indentation, but after coding for a while in SCSS I’ve realized that I really like having the option to put a couple of attribute/value pairs on the same line. I don’t always write it this way.

Normally, I write in expanded format with an attribute/value pair per line. But the compressed syntax is helpful when I only have an attribute/value pair or two. I especially like it for changing the color of a font for a hover state or adding an underline to a link.

For me SCSS ends up being more logically grouped than Sass. I can compress code that would take several lines in the Sass syntax into just a couple of lines of SCSS. Typically rules are grouped anyway. And when reading code, the number of lines of code that a bit of code uses tends to indicate its importance.

In SCSS I can compress lines that are fairly standard. And expand across several lines when I’m doing something complicated.

Reason #2: SCSS encourages proper nesting of rules

One of the huge advantages of Sass in general is that it allows you to nest selectors within selectors. This is awesome because when you change the “name” of an element, you only need to change it in one place (the outer selector) instead of in numerous places like you would when writing CSS.

But to quote Spiderman, with great power comes great responsibility.

And with the Sass syntax it really is true. It is too much power. At least for someone like me. Sass code I write tends to get too deeply nested. Why? Because it’s too easy to do. Every-time you nest something in Sass you need to be conscious of the impact that it is having on your output code.

Deeply nested Sass produces CSS with really long selectors. Especially if you use the comma operator at a high level (which is probably the most dangerous aspect of nesting). Not only is this bad because it increases the file size of the final CSS, too much specificity can become really hard to override in other rules. Importance is the result. You find yourself using !important in anger with fists in the air just to get a rule applied correctly.

Reason #3: SCSS encourages more modular code with @extend

Because nesting is harder in SCSS I find myself using @extend a lot more frequently. I tend to write code that is nested 1 – 2 levels deep underneath an abstract or virtual class name that is then extended by other selectors. Again, the curly braces, which are “ugly”, help me recognize when my code is too deeply nested and force me down the path of writing more modular code.

Oh, and if you’re not using the @extend directive, you are really missing out on the awesome-sauce of Sass! Experts agree. 🙂

Reason #4: SCSS allows me to write better inline documentation

It’s true that the Sass syntax allows a certain amount of flexibility with comments, but I find myself writing more inline-documentation directly in SCSS than Sass. A lot of this has to do with the way the code hangs together and the flexibility in syntax that SCSS provides. Braces help me group my code and comments in a way that makes more sense to me. I know we are talking aesthetics here, but more flexibility makes a difference when writing documentation.

Reason #5: Existing CSS tools often work with SCSS

I don’t actually use a lot of other tools with my CSS, but one area where this is particularly helpful is syntax highlighting. Depending on your editor preference, it may or may not have support for the indented Sass syntax. But most editors already have built-in support for CSS and tend to work well with SCSS. Also, if you do any blogging, most code highlighters support CSS, but only a handful support the Sass syntax.

Reason #6: Integration with an existing CSS codebase is much easier

I’ve often had to integrate with other CSS code when building a web site. It’s either code from some jQuery library I’m using, or a pre-existing CSS codebase. In the past I’ve often converted that code to Sass and lost valuable hours in the conversion process.

For a library, the downside is that it’s not code that you really want to maintain. When upgrading the library, the last thing you want to do is to go through the conversion process again. If it’s an existing codebase, it’s often much better to make smaller changes, than to jump into a megalithic refactoring process right away.

SCSS lets you use the existing code as is, and incrementally re-factor as you go along.

It’s true that with the indented syntax the sass-convert tool can get you most of the way there, but it’s never a completely clean conversion.

Reason #7: SCSS provides a much lower barrier to entry

From a Sass advocacy perspective, it’s much easier to convince someone to use SCSS than Sass. It’s easier to introduce them to a couple new concepts (SCSS) rather than an entirely new syntax. Designers can be very stubborn, caggy people. They are opinionated, and wary of change. They tend to do what they know well and while they do experiment with new things, experimentation with new technology is not built into the design community like it is for the programming community.

And don’t forget the other barriers to getting started with Sass. Right now you need to be familiar with the command prompt. At least enough to run a couple of commands. The command prompt is scary to the mouse-driven, button clicking designer.

Reason #8: SCSS could become the next version of CSS

Since its creation Sass and languages like it have attracted the attention of a lot of smart people. Some of those people are already thinking about adding some of the features that Sass introduced to CSS. It’s possible that the syntax introduced in SCSS could become CSS4!

Conclusion

I hope I’ve challenged you a little in your own perspective on both syntaxes. While I’m clearly arguing the advantages of the SCSS syntax, I’d also like to encourage you to go outside of your comfort zone and experiment a little more. If you’ve only been exposed to the SCSS syntax, perhaps you’d enjoy spending some time with the indented Sass syntax. And if you’re an original-flavor-only kinda person – a purist – you may benefit from giving the SCSS syntax a serious try.

As I said before, there are a lot of good people on both sides of the line in this debate. Feel free to express your own opinion in the comments below.

Editor’s Note

We’ve also setup a Wrangl to make sense of both sides of the argument.

OOCSS Principles, why even bother?

Leave a Comment

Object-Oriented CSS (OOCSS) is a methodology that applies object-oriented principles to CSS to enhance both the performance and maintainability of stylesheets. By encouraging code reuse and modular design, OOCSS seeks to reduce repetition and streamline development, making stylesheets easier to scale and maintain.

Key Principles of OOCSS

  1. Separation of Structure and Skin
    • Structure refers to properties like width, height, margins, padding, and positioning.
    • Skin refers to visual properties like colors, fonts, borders, and shadows.
    • By separating these, you can reuse structure-related styles across various elements while applying different skins to customize their appearance.
  2. Separation of Containers and Content
    • Styles should be independent of the specific container in which they are used, allowing them to be reused across different parts of a webpage.
    • Avoiding descendant selectors and styling based on container contexts helps make your CSS more modular.

Benefits of OOCSS

  1. Faster Websites: Reducing repetitive styles results in smaller CSS files, which load faster.
  2. Scalability: You can reuse styles easily as your project grows, making it simpler to scale CSS for large applications.
  3. Maintainability: Modular styles are easier to track, debug, and modify. When new developers join a project, they can extend or reuse existing styles without creating complex or conflicting rules.
  4. Efficiency: Having less code to maintain and apply makes development quicker and more efficient.
  5. Readability: Well-structured OOCSS makes it easier for other developers to understand your code.

Example of Applying OOCSS

Instead of repeating styles for multiple elements, OOCSS encourages you to abstract common styles into reusable classes.

Before OOCSS:

#button {
    width: 200px;
    height: 50px;
    background: #ccc;
    border: 1px solid #ccc;
    box-shadow: 2px 2px 5px rgba(0, 0, 0, 0.5);
}
#box {
    width: 400px;
    background: #ccc;
    border: 1px solid #ccc;
    box-shadow: 2px 2px 5px rgba(0, 0, 0, 0.5);
}
CSS

After OOCSS:

.button {
    width: 200px;
    height: 50px;
}

.box {
    width: 400px;
}

.skin {
    background: #ccc;
    border: 1px solid #ccc;
    box-shadow: 2px 2px 5px rgba(0, 0, 0, 0.5);
}
CSS

Now, you can apply the skin class to multiple elements to reuse the visual properties.

Understanding Object-Oriented CSS (OOCSS)

As web development continues to evolve, the complexity of managing CSS grows with it. With the rise of interactive web applications and intricate designs, developers are increasingly turning to methodologies that offer more structure and maintainability to their stylesheets. One such methodology is Object-Oriented CSS (OOCSS), proposed by web developer Nicole Sullivan in 2008. OOCSS applies principles from object-oriented programming to CSS, allowing developers to create reusable, scalable, and maintainable styles. This article delves into the core principles of OOCSS, its advantages and disadvantages, and how it can significantly improve the performance and maintainability of web pages.

The Principles of OOCSS

At the heart of OOCSS are two main principles: the separation of structure from skin, and the separation of containers from content.

1. Separation of Structure from Skin

The first principle of OOCSS focuses on distinguishing between the structural properties of an element and its visual properties. In web design, structure refers to the layout aspects of an element, such as size, padding, and positioning, while skin refers to the aesthetic aspects, such as color, font, and texture. By separating these two aspects, developers can create modular components that can be reused across different contexts.

Example:

Before OOCSS Implementation:

.button {
    width: 150px;
    height: 50px;
    background: #FFF;
    border-radius: 5px;
}

.button-2 {
    width: 150px;
    height: 50px;
    background: #000;
    border-radius: 5px;
}
CSS

In the above code, there is a lot of repetition, particularly in defining width, height, and border-radius.

After OOCSS Implementation:

.skin {
    width: 150px;
    height: 50px;
    border-radius: 5px;
}

.button {
    background: #FFF;
}

.button-2 {
    background: #000;
}
CSS

Here, the structural styles are abstracted into a reusable .skin class, which can be combined with different skin classes. This reduces redundancy and makes it easier to manage the CSS.

2. Separation of Containers from Content

The second principle emphasizes separating the styling of containers from their content. This ensures that styles applied to elements are not overly dependent on their parent containers, which enhances reusability and predictability.

Example:

Before OOCSS Implementation:

#sidebar {
    padding: 2px;
    left: 0;
    margin: 3px;
    position: absolute;
    width: 140px;
}

#sidebar .list {
    margin: 3px;
}

#sidebar .list .list-header {
    font-size: 16px;
    color: red;
}

#sidebar .list .list-body {
    font-size: 12px;
    color: #FFF;
    background-color: red;
}
CSS

In this example, the styles are tightly coupled with the #sidebar container, making it difficult to reuse the .list, .list-header, and .list-body classes outside of that context.

After OOCSS Implementation:

.sidebar {
    padding: 2px;
    left: 0;
    margin: 3px;
    position: absolute;
    width: 140px;
}

.list {
    margin: 3px;
}

.list-header {
    font-size: 16px;
    color: red;
}

.list-body {
    font-size: 12px;
    color: #FFF;
    background-color: red;
}
CSS

With OOCSS, the container and content styles are defined independently. This modular approach allows developers to reuse styles more effectively across different components, regardless of their context in the document.

Advantages of OOCSS

The benefits of adopting OOCSS are manifold, especially for larger projects where CSS can quickly become complex and unwieldy.

1. Faster Websites

By minimizing repetitive styles, OOCSS helps reduce the size of CSS files. Smaller stylesheets lead to faster download times, improving the overall performance of web pages. Although it may introduce a slight increase in the HTML file size due to additional class attributes, the performance gains from optimized stylesheets often outweigh this drawback.

2. Maintainable Stylesheets

OOCSS encourages the creation of a maintainable stylesheet by reducing specificity conflicts and fostering a modular approach. Rather than creating unique styles for each component, developers can leverage existing modules, making updates and additions much easier. As projects evolve, new components can be built on top of existing styles, ensuring consistency and reducing the likelihood of introducing bugs.

3. Scalability

OOCSS supports scalable design by allowing developers to reuse style modules across various elements. As a project grows, developers can freely combine and reapply classes without worrying about specificity or conflicts. This is particularly beneficial in larger teams where different developers may work on different components.

4. Enhanced Readability

With its focus on modular design, OOCSS makes CSS more readable. Other developers can quickly understand the structure and intent of the styles, which is crucial for collaboration. Clear naming conventions and organized class structures improve communication and reduce the learning curve for new team members.

5. Efficiency

Fewer lines of code mean that developers can scan and edit styles more efficiently. When styles are defined once and reused, the development process becomes more streamlined, allowing for quicker iterations and modifications.

6. Reduced Duplication of Efforts

By following the DRY (Don’t Repeat Yourself) principle, OOCSS eliminates redundant styles. This not only saves time but also reduces the chances of inconsistencies that can arise when multiple developers inadvertently create similar styles.

Disadvantages of OOCSS

While OOCSS offers numerous benefits, it is not without its challenges. Developers should be aware of these potential downsides when considering its implementation.

1. Learning Curve

For developers unfamiliar with object-oriented programming principles, adapting to OOCSS can take time. Understanding the concepts of separation and modularity may require a shift in mindset, especially for those accustomed to traditional CSS practices.

2. Increased HTML Markup

One criticism of OOCSS is that it can lead to more cluttered HTML markup due to the increased use of classes. This can make the HTML harder to read, particularly in simpler projects where a lightweight structure is preferable. However, the trade-off is often worthwhile for larger applications where maintainability and performance are critical.

3. Overhead for Small Projects

For smaller projects or simple static sites, the overhead of implementing OOCSS may not be justified. In such cases, a more straightforward approach might be sufficient, as the benefits of modular CSS become more apparent in larger, more complex applications.

4. Potential for Over-Engineering

In an effort to adhere to OOCSS principles, developers might over-engineer their CSS, creating unnecessary abstractions. It is essential to strike a balance between modularity and simplicity, ensuring that styles remain straightforward and easy to understand.

Real-World Example: Applying OOCSS

To illustrate how OOCSS can be effectively applied in a real-world scenario, consider the design of a web page featuring multiple button styles and layout containers.

Initial CSS (without OOCSS):

.button-primary {
    width: 120px;
    height: 40px;
    background-color: blue;
    color: white;
    border-radius: 5px;
}

.button-secondary {
    width: 120px;
    height: 40px;
    background-color: grey;
    color: black;
    border-radius: 5px;
}

.container {
    width: 960px;
    margin: 0 auto;
    padding: 20px;
}
CSS

In this example, the button styles are not reusable, leading to duplication of properties.

Refactored CSS (with OOCSS):

.button {
    width: 120px;
    height: 40px;
    border-radius: 5px;
}

.button-primary {
    background-color: blue;
    color: white;
}

.button-secondary {
    background-color: grey;
    color: black;
}

.container {
    width: 960px;
    margin: 0 auto;
    padding: 20px;
}
CSS

By introducing a base .button class for shared properties, the code becomes more modular and maintainable.

Guidelines for Implementing OOCSS

Getting started with OOCSS may require some adjustments to your development practices. Here are a few guidelines to help you transition to an OOCSS mindset:

  1. Avoid Descendant Selectors: Focus on using class-based selectors rather than descendant selectors to ensure styles are reusable.
  2. Favor Classes Over IDs: Rely primarily on classes for styling rather than IDs, as classes provide more flexibility and avoid specificity issues.
  3. Modularize Styles: Identify repeating patterns in your CSS and create reusable modules that can be applied across different elements.
  4. Use Naming Conventions: Establish clear naming conventions for classes that reflect their purpose and usage, improving readability and maintainability.
  5. Utilize Tools: Consider using tools like CSS Lint to check for code quality and adherence to OOCSS principles.

Conclusion

Object-Oriented CSS (OOCSS) is a powerful methodology that can significantly enhance the performance, maintainability, and scalability of web stylesheets. By embracing the principles of separation of structure from skin and separation of containers from content, developers can create modular, reusable components that streamline the development process. While OOCSS may not be suitable for every project, particularly smaller ones, its advantages become increasingly apparent as web applications grow in complexity. By adopting an OOCSS approach, developers can produce faster, more efficient, and easier