Sass/SCSS does not enable/recognize the use of CSS Grid Layout's named lines & template area syntax

[lozandier]

With the current versions of Sass/SCSS, users cannot reliably be able to use CSS Grid Layout Module Level 1's named line syntax or its template.

It seems a moderate issue since the Grid Layout Module has had the latter a very mature & stable feature with its availability in modern browsers such as Edge (the others are removing Grid Layout module from their flag real soon) for some time (+2 years) & the former has also been a stable feature in the spec for years now but merely had named lines surrounded by square brackets (see example below) about ~6-8 months ago.

With the module mature enough to consider for serious prototyping with it & legitimate anticipation for its availability this year in Safari 7 & upcoming versions of Firefox & Chrome this year outside of flags, it seems worthwhile to make this officially an issue.

Example 1: Named line syntax not being able to work w/ Sass/SCSS

The following code utilizing CSS Grid named lines capabilities will error out by Sass

.wrapper 
  display: grid
  grid-template-columns: [col1-start] 9fr [col1-end] 10px [col2-start] 3fr [col2-end] // This will cause Sass to throw errors 
  grid-template-rows: auto

Example 2: grid-template-areas not being able to work w/ Sass/SCSS

.wrapper 
  display: grid
  width: 90%
  margin: 0 auto
  grid-template-columns: 9fr 1.875em 3fr
  grid-template-rows: auto
  grid-template-areas:   
    "header header header"
    "content . sidebar"
    "footer footer footer"
    // ^ The following will throw 

[chriseppstein]

For example 2, this is merely formatting, the browser will happily recognize the following:

.wrapper 
  // ...
  grid-template-areas: "header header header" "content . sidebar" "footer footer footer"

So this aspect is a duplicate of #216.

[lozandier]

@chriseppstein Thanks for the clarification regarding example 2, being aware of #216, didn't think it'll apply to CSS constructs in addition to Sass constructs such as maps…

Didn't think to write my intended value for grid-template-areas that way before.

[chriseppstein]

Example 1 will require some non trivial changes to our parser. From the spec, we need to be able to parse <line-names> = '[' <custom-ident>* ']'. Our current thinking is that this is a new kind of list syntax. Here's the plan.

Our parser will allow any list (both space and comma delimted) to be wrapped in brackets. Those brackets will be printed if the list is output directly to the CSS output. In this sense, brackets are like quotes on strings.

New List API Example

$bracket-list: [foo bar];
$header-1: nth($bracket-list, 1); // => foo
$space-list: unbracket($bracket-list); // => foo bar
$given-brackets: bracket((a b c)); // => [a b c]
$bracket-list-separator: list-separator($bracket-list); // => space
$is-bracketed: is-bracketed($bracket-list); // => true

Note that all of the above examples would work with comma delimited lists.

New List API Reference

New grammar for the script value parser: "[" (<value> <space>+)* <value>? || (<value> <space>* "," <space>*)+ (<value> <space>* ","? <space>*)? "]"

Ruby Value API Changes:

• New Property for Sass::Script::Value::List: bracketed? Boolean. Indicates whether the list is surrounded by square brackets.

Sass API Changes:

• New function: is-bracketed($list) Returns a boolean indicating whether the List is bracketed. Errors if the argument is not a list or simple value. For simple values, this function returns false.
• New function bracket($list) Returns a copy of $list with the bracketed? property set to true. Returns the existing list if bracketed? is already true.
• New function unbracket($list) Returns a copy of $list with the bracketed? property set to false. Returns the existing list if bracketed? is already false.

Miscellaneous:

• Lists with equal elements will only be considered equal (==) if they have the same value returned by is-bracketed().

Things Worth Noting ™

• Bracketed lists provide a companion to (foo,) which defines a single element comma list using [foo] which will default to being space delimited unless there is a trailing comma.
• Bracketed lists allow for a zero-element space delimited list with [].

[nex3]

I'm mostly on board. Just a couple nits. First, I think unbracket() would be nicer than debracket(), since it parallels unquote() for strings. Second:

Bracketed lists by their nature allow for arbitrary-depth of syntactic nested lists -- this is nonsensical for CSS output, but handy for many scripting tasks. Before bracketed lists, syntactic nesting of lists only allowed for a depth of 2 -- deeper nesting required the use of Sass functions.

I don't think this is right? You can write (foo (bar (baz bang))), for example.

[chriseppstein]

First, I think unbracket() would be nicer than debracket(), since it parallels unquote() for strings.

Agreed. I updated the spec above.

I don't think this is right? You can write (foo (bar (baz bang))), for example.

Good point. Removed.

Another thing: We need to decide if brackets affect list equality. the separator does, but quotes in strings don't (which I increasingly think was a mistake). I updated the spec to address this.

[xzyfer]

Can I suggest this feature be accompanied by a feature flag?

[chriseppstein]

@xzyfer I'm not opposed, but we create feature flags when the syntax is backwards compatible but the semantics change. What point would a flag serve? It would be a syntax error during compilation if the new syntax is encountered.

[xzyfer]

I think the feature would be regarding the ability to parse the grid syntax. Library authors could (maybe?) fallback to string concatenation and unquoting. I'm not very familiar with the grid spec but off the top of my head this gets the job done.

foo {
  bar: unquote("[foo] 1 [bar] 2");
}

Maybe the point is moot without conditional @imports.

[chriseppstein]

Maybe the point is moot without conditional @import.

@xzyfer Exactly. All sass files are parsed and there's no way to avoid the syntax error by scripting.

[tabatkins]

While the CSSWG reserves the right to use bracketed groups in arbitrary ways, I intend for it to only be used rarely, and to contain lists. I leave open as a reasonable possibility that future lists may be comma-separated.

[lozandier]

@chriseppstein @nex3 @tabatkins This all makes sense to me. Thanks @xzyfer for reminding me to not forget about the awesomeness of unquote.

[nex3]

Lists with equal elements will only be considered equal (==) if they have the same value returned by is-bracketed().

👍