New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
lozandier opened this Issue Jan 9, 2016 · 19 comments

Comments

Projects
None yet
8 participants
@lozandier
Copy link

lozandier commented Jan 9, 2016

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

This comment has been minimized.

Copy link
Member

chriseppstein commented Jan 11, 2016

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

This comment has been minimized.

Copy link
Author

lozandier commented Jan 11, 2016

@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

This comment has been minimized.

Copy link
Member

chriseppstein commented Jan 11, 2016

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

This comment has been minimized.

Copy link
Contributor

nex3 commented Jan 11, 2016

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

This comment has been minimized.

Copy link
Member

chriseppstein commented Jan 11, 2016

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

This comment has been minimized.

Copy link
Contributor

xzyfer commented Jan 11, 2016

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

@chriseppstein

This comment has been minimized.

Copy link
Member

chriseppstein commented Jan 12, 2016

@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

This comment has been minimized.

Copy link
Contributor

xzyfer commented Jan 12, 2016

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

This comment has been minimized.

Copy link
Member

chriseppstein commented Jan 12, 2016

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

This comment has been minimized.

Copy link

tabatkins commented Jan 13, 2016

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

This comment has been minimized.

Copy link
Author

lozandier commented Jan 13, 2016

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

@nex3

This comment has been minimized.

Copy link
Contributor

nex3 commented Jan 15, 2016

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

👍

@chriseppstein chriseppstein added this to the 3.5 milestone Mar 11, 2016

nex3 added a commit to sass/sass-spec that referenced this issue Apr 30, 2016

nex3 added a commit that referenced this issue Apr 30, 2016

@nex3 nex3 closed this Apr 30, 2016

@nex3

This comment has been minimized.

Copy link
Contributor

nex3 commented Apr 30, 2016

This is implemented to spec, with the exception that we decided to use join() to control bracketedness rather than bracket() and unbracket() to match the way list separators are manipulated.

@chidoukaigwe

This comment has been minimized.

Copy link

chidoukaigwe commented Jan 21, 2018

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?

@silaswanders

This comment has been minimized.

Copy link

silaswanders commented Feb 24, 2018

I'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

@nex3

This comment has been minimized.

Copy link
Contributor

nex3 commented Mar 2, 2018

@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?

@waltercruz

This comment has been minimized.

Copy link

waltercruz commented Mar 13, 2018

I'm getting a similar error using node-sass (using libsass 3.6). Should I report it here?

@nex3

This comment has been minimized.

Copy link
Contributor

nex3 commented Mar 13, 2018

Errors from LibSass should be reported against https://github.com/sass/libsass

@waltercruz

This comment has been minimized.

Copy link

waltercruz commented Mar 13, 2018

ok, thanks @nex3 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment