Repository navigation
Sass/SCSS does not enable/recognize the use of CSS Grid Layout's named lines & template area syntax #1963
Description
Activity
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.
Reacted by Yulia Kostyuchenko, Alexander Volkov, Snorre Aas, cagri, Rusydy, Déborah Ballaminut, ManuelFernandezEsteban and Mike LeeReacted by bigkrp, champanja, Boris Diakur, Fernando Gelin, cagri and Andrei Costiv@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-areasthat way before.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$listwith thebracketed?property set to true. Returns the existing list ifbracketed?is already true. - New function
unbracket($list)Returns a copy of$listwith thebracketed?property set to false. Returns the existing list ifbracketed?is already false.
Miscellaneous:
- Lists with equal elements will only be considered equal (
==) if they have the same value returned byis-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
[].
- New Property for
I'm mostly on board. Just a couple nits. First, I think
unbracket()would be nicer thandebracket(), since it parallelsunquote()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.First, I think
unbracket()would be nicer thandebracket(), since it parallelsunquote()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.
Can I suggest this feature be accompanied by a feature flag?
@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.
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.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.
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.
@chriseppstein @nex3 @tabatkins This all makes sense to me. Thanks @xzyfer for reminding me to not forget about the awesomeness of
unquote.Lists with equal elements will only be considered equal (
==) if they have the same value returned byis-bracketed().👍
- added this to the milestone
on Mar 11, 2016 - added 2 commits that reference this issue
on Apr 30, 2016 This is implemented to spec, with the exception that we decided to use
join()to control bracketedness rather thanbracket()andunbracket()to match the way list separators are manipulated.How does this work? - I am trying to implement CSS Grid names within my SASS which is being compiled by Scout App - I have read the above information, but I am still confused on how to implement it. Can somebody help me please?
Reacted by Ian Gloude, Louis Sayers, Sidney Liebrand, Russell Bishop, Silas, Keith J. Grant, Maël Mayon and Evelyn SchmitzI'm in the same boat as @chidoukaigwe I've read the above, but it's just very confusing and technical. I'm also using scout app and something like
grid-template-columns:
[full-start] minmax(1em, 1fr)
[main-start] minmax(0, 40em) [main-end]
minmax(1em, 1fr) [full-end];
is rejected@chidoukaigwe @silaswanders This should just work as long as you're using a recent version of Sass. What version are you using, and what error are you seeing?
I'm getting a similar error using node-sass (using libsass 3.6). Should I report it here?
Reacted by Evelyn SchmitzErrors from LibSass should be reported against https://github.com/sass/libsass
ok, thanks @nex3 !
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
Example 2:
grid-template-areasnot being able to work w/ Sass/SCSS