Allow SCSS syntax blocks in the indented syntax

[jamesnw]

As part of the Indented syntax improvements proposal, a SCSS-in-Sass format was proposed in #3973. This was removed in #4002 based on feedback in #3991.

This syntax would allow authors to opt in to SCSS format for part of the document. A few of the use cases that were mentioned-

1. A terser option for short styles, for instance a {color: red}.
2. An inline alternative for authors who import .scss files that contain long values, for instance grid template or font declarations.
3. Useful for migrating existing stylesheets to the SCSS format.

[oscarmarcelo]

I'm very excited to find out that line breaks in Sass syntax are finally in the roadmap! 🎉

About this issue, and from the front-end development view (as I'm not familiar with Dart, much of the Sass internal code, or the language server subject that has been raised in the linked issues), here's my feedback:

Priority

I do agree that CSS-in-Sass isn't an appreciated feature as much as multiline statements are, but it is still very welcome, just like you mentioned in the three cases.

Availability

I didn't find any mention of using SCSS at the top level. Is it being considered or will it only be available inside declaration blocks? As an example, will something like this be allowed?

div
  color: blue

{
  $ipsum: red;

  a {
    color: $ipsum;
  }
}

Also, if the SCSS block is nested in a declaration rule, does everything in it work as expected in regards of nesting? An example:

div
  color: blue

  {
    $ipsum: red;
  
    a {
      color: $ipsum;
    }
  }

Alternative to using lists and others

I understand and agree in using lists and other similar methods to allow line breaks to occur and not break the current syntax or introduce breaking changes to Sass.

But precisely because of this, I see having SCSS blocks as an alternative and familiar way to write multiline statements without having to resort to the mentioned methods when authoring code that may be hard to read, like lists and maps with a considerable amount of nested levels and/or with a lot of SassScript, potentially bringing additional noise to the code.

It may seem a "you're overcomplicating your code" thing, but I still think it should be considered.

AST

I'll assume that when the AST feature is released, there isn't going to be any differences to the output whether a specific code is in Sass syntax or in a SCSS block, right?

As a bonus, maybe a property stating the syntax used in that specific code location, or whether that specific code is inside a SCSS block, would also be interesting.

---

That being said, I would still love to see this being implemented, but I'm OK if it doesn't come out at the same time as the features from the Sass improvements proposal, if at all.

I would like to also hear what others have to say, specially about the concerns raised in the other issues that lead to the removal of this feature from the proposal, as I'm not aware of the implications related to those, like the language servers that were mentioned.

[jamesnw]

@oscarmarcelo Thanks for adding your use cases and questions.

A couple notes in response to the Availability section-

As proposed, in the indented syntax, you could denote a block using either indentation or curly braces. In other words, the SCSS block only replaces existing Sass blocks, and doesn't allow blocks in new places.

In the top level example, the curly braces would not add any benefit- semicolons will be allowed in #3973, and this issue would add the {} syntax to support the a rule. Are there use cases where requiring a series of statements be in SCSS format outside of a block would be useful?

For the nested example, this would be similar to-

div {
  color: blue;
  {
    $ipsum: red;
    a {
      color: $ipsum;
    }
  }
}

This doesn't currently work in SCSS, and I can't think of a use case for a block without a selector. I don't think this would be supported.

[oscarmarcelo]

@jamesnw

TLDR: You're right, I was overcomplicating things.
(You don't have to keep reading. The following is to explain my train of thought.)

---

Sorry, maybe my example wasn't the best for what I was trying to explain. And it kind of mixes with the "Alternatives (...)" section too.

Consider the following, where the author would want to have a multi level list at the top level:

// Invalid in Sass, without parentheses wrapping the whole statement.
$lorem: ipsum dolor,
  sit true (
    amet, red, consectetur,
    (
      0, 2px, 4px
    )
  ) 100


// But would be valid in a SCSS block.
{
  $lorem: ipsum dolor,
    sit true (
      amet, red, consectetur,
      (
        0, 2px, 4px
      )
    ) 100;
}

Another example here.

But now looking back at these examples, I agree that maybe it doesn't make sense.

In my mind at the time I was writing the first comment, I thought that I would need to wrap every level to make it valid in multiline statements, but that already happens in the current Sass version, as we need to wrap nested lists, and then there's the rule that line breaks can occur while a statement can't end, so the first parentheses would still be in effect in nested lists.

Also, the amount of characters needed to make a multiline statement would be the same (() vs {} ignoring whitespace).

One could also be picky about the amount of characters and say that we would save some when wrapping multiple variables in a SCSS block instead of wrapping each variable in parentheses, but yeah, probably it isn't worth the effort of the additional complexity needed to make this possible.

Sorry I took your time with this. 🙏

[jamesnw]

Sorry I took your time with this. 🙏

No worries! Thank you for providing examples and for your feedback!

[MrSuddenJoy]

I try to mean there is nothing wrong in indenting some block(s) as needed and these blocks should get the formatting/coloring of parent block.

If not, than just add declaration to config file.

[stof]

I'll assume that when the AST feature is released, there isn't going to be any differences to the output whether a specific code is in Sass syntax or in a SCSS block, right?

Both syntaxes produce the same AST as the output of parsing. Both syntaxes are lexical syntaxes for the same Sass language.
The 2 syntaxes are separate only at the parser level (which is why having both syntaxes does not add a huge maintenance cost for each new feature of Sass, especially given that over 95% of the parser code is shared).