Multiline Expressions in Indented Syntax

[talsafran]

Edited by @nex3 to change the title.

[cross-posted from http://stackoverflow.com/questions/8248976/sass-indented-syntax-on-multiple-lines]

I love indented syntax, I think it's much cleaner.

There's one issue I have with it. If I have a really long mixin declaration, there's no way to split it into multiple lines (obeying the 80 character limit, for example)

Take this example, first written in SCSS.

@mixin col($cols, $mleft: 0, $mright: 0, $include-margin: false, $border: 0,
           $pleft: 0, $pright: 0, $include-padding: true, $extra: 0, 
           $clear: false, $lead: true, $container: false) {
    color: red;
    display: block;
}

I'm able to split up one long declaration in to multiple lines. With the indented syntax, I don't think there's a way. I have to put the declaration on one line, which is way less readable.

@mixin col($cols, $mleft: 0, $mright: 0, $include-margin: false, $border: 0, $pleft: 0, $pright: 0, $include-padding: true, $extra: 0, $clear: false, $lead: true, $container: false)
    color: red
    display: block

Is there some way I don't know of? And if not, can there be one? :)

[miracle2k]

I also think sass should support this, and not just in mixins. It's a serious deficiency in the indented syntax.

[pengwynn]

+1 Haml allows multi-line statements if lines end with a comma.

[talsafran]

@pengwynn I like that approach. It's nicer than the way I was thinking, which was adding a \ to the end of line like in Python.

[cybersquid]

Just ran into this myself. It's a real problem. box-shadow statements can be really long.

[Anahkiasen]

+1

[while0pass]

+1
another example of currently valid, but not very readable src property in @font-face rule

@font-face
    font-family: 'SPEdessa'
    src: url('fonts/spedessa-webfont.eot')
    src: url('fonts/spedessa-webfont.eot?#iefix') format('embedded-opentype'), url('fonts/spedessa-webfont.woff') format('woff'), url('fonts/spedessa-webfont.ttf') format('truetype')
    font-weight: normal
    font-style: normal

and currently invalid for SASS, but much more readable:

@font-face
    font-family: 'SPEdessa'
    src: url('fonts/spedessa-webfont.eot')
    src: url('fonts/spedessa-webfont.eot?#iefix') format('embedded-opentype'),
         url('fonts/spedessa-webfont.woff') format('woff'),
         url('fonts/spedessa-webfont.ttf') format('truetype')
    font-weight: normal
    font-style: normal

[olivierlacan]

I've faced a similar issue yesterday when defining a @font-face in Sass.

This feature would have the potential to increase legibility substantially.

Is anyone here familiar enough with how Sass parses lines to have a vague idea how to go about implementing this, or if it's even worth the effort?

[adamkiss]

+1

[mohsen1]

Can we at least have JavaScript like multi-line with a \ at end of each line?

background-image: radial-gradient($color, $color $thickness/2, transparent $thickness/2),\
 radial-gradient($color, $color $thickness/2, transparent $thickness/2)

[firedev]

Just stumbled onto the super-long line and the first thing I tried was \ at the end of line, sadly it wasn't working.

[averyvery]

👍

[DavidOliver]

👍 It would be very nice for nested lists, too.

$list:
    (1,  "value"), (5,  "value"), (23, "value"), (85, "value"), (32, "value"), (11, "value"), (35, "value"), (89, "value")

$list:
    (1,  "value"),
    (5,  "value"),
    (23, "value"),
    (85, "value"),
    (32, "value"),
    (11, "value"),
    (35, "value"),
    (89, "value")

[IanOliver]

Agreed. Multi-line would be a very welcome addition for mixins and lists.

The whitespace-aware/inferred nature of the indented syntax is the primary reason I chose it over SCSS (and, I assume, it's existence).

As mentioned by others, the readability of box-shadows, text-shadows, @font-faces and lists would benefit hugely from this.

[lolmaus]

Selectors too. Sometimes they can be very long.

It's a pity that Sass can't do multiline expressions. The funny thing is that Haml does allow breaking the line after a comma.

[firedev]

@lolmaus Here is a sample of my HAML code, and I don't really like it, am I doing it wrong? AFAIK Haml doesn't allow you to simply end a line with comma.

  = text_field :inquiry, |
        :customer, |
        placeholder: 'Customer', |
        id: 'suggest_customer', |
        value: (params[:inquiry][:customer] if params.fetch(:inquiry, false)), |
        data: { |
          action: suggest_customer_supervise_or_manage_users_path, |
          email: 'q[name_or_email_cont]' |
        } |

[lolmaus]

@firedev Does it work when formatted like this?

= text_field :inquiry, :customer, placeholder: 'Customer',
                                  id:          'suggest_customer',
                                  value:       (params[:inquiry][:customer] if params.fetch(:inquiry, false)),
                                  data:        { action: suggest_customer_supervise_or_manage_users_path,
                                                 email: 'q[name_or_email_cont]' }

A shorter way:

= text_field :inquiry,
             :customer,
             placeholder: 'Customer',
             id:          'suggest_customer',
             value:       (params[:inquiry][:customer] if params.fetch(:inquiry, false)),
             data:        { action: suggest_customer_supervise_or_manage_users_path,
                            email: 'q[name_or_email_cont]' }

I didn't test it, but i format my Haml code similarly and it works.

TL/DR: You don't need a pipe in the end of a line of Haml code if the line ends with a comma.

[firedev]

I'll be damned! It does, what is the trick here? I tried it before and always had to pipe it up.

Guess the problem was caused by me trying to have curly braces on new lines for data:

data: {
  ...
}

[pdufour]

+1

[mxlje]

Is there any progress on this?

I’m running into similar issues when trying to use maps in Sass 3.3.5. While when using the scss syntax everything works perfectly like so

$susy: (
  columns: 12,
  gutters: 1/3,
  gutter-position: after,
  math: fluid,
  output: float,
  flow: ltr,
  global-box-sizing: border-box
)

something like (using .sass)

$susy:
  columns: 12,
  gutters: 1/3,
  gutter-position: after,
  math: fluid,
  output: float,
  flow: ltr,
  global-box-sizing: border-box

doesn’t, because Nothing may be nested beneath variable declarations.. While writing it on a single line may work, it’s really hard to read, hits 80 char limits really fast and kind of defeats the purpose of the indented syntax, no?

[BenjaminHolm]

I agree with mxlje. The .sass syntax is beautiful but maps really tear things up.

[Malet]

Found this thread from http://stackoverflow.com/q/23429137/174034 - I'm having similar problems

[Arcovion]

+1

[starwilly]

+1

[nicooprat]

+1, maybe we should start a bounty for this everlasting issue ?

[roytomeij]

Only now find out about this issue. +1

[alromh87]

Feels like it's time to get this solved 😉

You can try it from https://github.com/alromh87/dart-sass/tree/multiline

1. Install dart
2. Clone repo git clone https://github.com/alromh87/dart-sass/tree/multiline
3. Go into dir dart-sass
4. Install dependencies
   pub get
5. Run
   dart dart bin/sass.dart testN.sass

You can use this file as reference, I tested the examples I found here
https://github.com/alromh87/sass-spec/blob/master/spec/multiline_sass/input.sass

[ngdangtu-vn]

@alromh87
Is it possible for you use the comma as separate line instead of /?

[alromh87]

@ngdangtu-vn while possible it would be more complicated and I wasn't aware that all this has to go over the language proposal process, so for now I will wait to see what comes out from this process.

I didn't expect this fix to be that complex 😅

[ngdangtu-vn]

@alromh87 Well, it can be help. I think if your PR got approved, it involves to a lot developers. And one it got publish, there will be no way to turn back. So let's way for it got approved. Anyway, thank you for your PR. I do hope it will pass soon 'cause I truly need it.

[mangelozzi]

@alromh87
Is it possible for you use the comma as separate line instead of /?

A comma would be confusing, list and maps are separeted by commas.
One of the most useful reason for multiline statements is for list and maps, which would then require two commas.
Is the comma a comman between items, or to join the line?? Hence why many language use a \

[ngdangtu-vn]

@mangelozzi

Is the comma a comman between items, or to join the line??

Can it do both? I don't understand why should we concern about it.

[alromh87]

It would be possible to avoid using any extra character (aka: detecting the coma) but since the parser works on a char level it would need to keep state when it should treat newline as single line.

For that it would be needed to specify where this behaviour should thake place. Would someone be willing to analyze and integrate one single list? Again I feel it make it more complex and probably will delay more the integration.

I sent proposal as implemented, lets wait an see the result, hopefully won't thake that long since it is allready a very long awaited feature (2011).

In the meantime you can follow the procedure detailed before to use it if you strongly need it now. Let me know if you have questions.

Also if someone would be willing contribute to the bounty to support development, I would appreciate it.

One more thing: once upon a time there was an implementation of this functionality for ruby sass that never landed due to unfortunate circumstances, this implementation also used backslash "\", so should not be too hard to syncronize ruby version as well. I hope unfortunate circumstances dont arrise again, and this issue can be finally closed.

Good vibes 🤙

[alromh87]

Hello, do any of you have any idea how this should be written?

#2921 (review)

[LandonSchropp]

Just to add another use case to this, this would be very helpful when using grid-template-areas:

grid-template-areas: 
  "primary-navigation primary-navigation" 
  "secondary-navigation sidebar" 
  "main sidebar" 
  "content-controls sidebar"

While this wouldn't be my first choice of syntax, as noted by other people, many other languages support this by using backslashes:

grid-template-areas: \
  "primary-navigation primary-navigation" \
  "secondary-navigation sidebar" \
  "main sidebar" \
  "content-controls sidebar"

[avesus]

What are the objective benefits of using SASS vs SCSS again, despite of this awkward yaml-style tabulation?

+1

[wouter-muller]

• it is cleaner and slightly easier to read and easier/faster to type, cause there is no need for the {, } and ; symbols
• Easier/shorter way of calling mixins, +mixin instead of @import mixin

@avesus

[Jorge-Gonzalez]

It is more consice, and compact, easier to read, IMO.

[EzraWolf]

Not trying to be rude, but is there a reason why this still hasn't arrived yet..? It has been so many years since this was first opened

[HamptonMakes]

@EzraWolf "Intended Sass" isn't actively being worked on or expanded– it's hardly known at all outside of the Ruby community who got used to it with the original design of Sass wayyy back over 16 years ago when that was the original style.

Over a decade ago we decided to pivot hard to using a 'css-compatible' style of Sass, and have made that the primary syntax ever since and has contributed to the expansion of the language.

In fact, I think it's kinda wild that Natalie has still kept the indented syntax functional after all these years of new features.

I'm not sure if @nex3 has officially commented on this ticket– so many comments to wade through– but I'd guess that she isn't really against it, but likely it's just not even anywhere near a priority with the usage that indented-syntax gets.

Honestly, it causes so much confusion and double-work (this ticket being an example) that I'm not sure how much longer it's even a good idea to keep it around!

[wouter-muller]

@HamptonMakes We love the indented syntax, I use it for all my projects (non Ruby or RoR projects but Vite apps and pure Vue SPA's), so please keep it around, we don't care about this multiline issue :)

[nex3]

To be clear: we have no plans to get rid of the indented syntax. I would definitely like to add multiline expressions—note that this issue is marked as "planned"—but it'll take a substantial design effort to ensure we get this right and the Sass team is stretched very thin.

[HamptonMakes]

What she said then! ^^

[rossbulat]

Sass syntax works very well with Tailwind CSS, this is giving developers a fresh perspective of whether to support indented syntax. Tailwind sass syntax (syntax highlighter only) for VS Code has had 37,086 installs at time of writing, and while not a huge amount, there is an obvious desire for the combo.