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

Liquid tags in SASS no longer work with version 2.1.0 #2573

Closed
travisneilson opened this Issue Jul 5, 2014 · 20 comments

Comments

Projects
None yet
10 participants
@travisneilson

travisneilson commented Jul 5, 2014

Hi! I was using liquid tags in my SASS compiled by Jekyll and it worked famously. But in 2.1 they no longer work.

I'm not sure if this feature broke, or if the way you go about it changed.

Here is the file I'm referring too: https://github.com/DevTips/Artists-Theme/blob/master/assets/css/all.sass
Lines 13-15

(I reverted to Jekyll 2.0.3 and it works fine again...)

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Jul 6, 2014

Member

Yes, we decided offering liquid in assets was a Bad Idea (tm). I'm on my phone right now and can't find the issue but we had a discussion. Basically, syntax tends to totally get fucked (i.e. clash)

Member

parkr commented Jul 6, 2014

Yes, we decided offering liquid in assets was a Bad Idea (tm). I'm on my phone right now and can't find the issue but we had a discussion. Basically, syntax tends to totally get fucked (i.e. clash)

@budparr

This comment has been minimized.

Show comment
Hide comment
@budparr

budparr Jul 6, 2014

Contributor

What happened to #2023 where it was left with you saying, @parkr:

With @imathis's support and fantastic explanation, let's try Sass with Liquid (just for Pages, not for imports, mind you) and see how it goes.

Contributor

budparr commented Jul 6, 2014

What happened to #2023 where it was left with you saying, @parkr:

With @imathis's support and fantastic explanation, let's try Sass with Liquid (just for Pages, not for imports, mind you) and see how it goes.

@travisneilson

This comment has been minimized.

Show comment
Hide comment
@travisneilson

travisneilson Jul 6, 2014

Oh. That's interesting. Thanks for letting me know. Kind of a bummer though, that was really exciting to me.

Is there another way to conversate between the two?

I'm trying to have a settings.yml where you can set everything including colors and images etc...

travisneilson commented Jul 6, 2014

Oh. That's interesting. Thanks for letting me know. Kind of a bummer though, that was really exciting to me.

Is there another way to conversate between the two?

I'm trying to have a settings.yml where you can set everything including colors and images etc...

@AJ-Acevedo

This comment has been minimized.

Show comment
Hide comment
@AJ-Acevedo

AJ-Acevedo Jul 6, 2014

Contributor

This would be really helpful for Jekyll themes! 👍

Contributor

AJ-Acevedo commented Jul 6, 2014

This would be really helpful for Jekyll themes! 👍

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Jul 7, 2014

Contributor

It wouldn't be too hard to build a set of Sass/SCSS/Less helpers that bring the Jekyll config in. The question is, does it get embedded into Jekyll, does it become a gem of it's own (say jekyll-style-helpers?) It would bug me a lot to do Sass/SCSS only and leave out Less but I would be more than happy to build this up tonight if people really want it.

Contributor

envygeeks commented Jul 7, 2014

It wouldn't be too hard to build a set of Sass/SCSS/Less helpers that bring the Jekyll config in. The question is, does it get embedded into Jekyll, does it become a gem of it's own (say jekyll-style-helpers?) It would bug me a lot to do Sass/SCSS only and leave out Less but I would be more than happy to build this up tonight if people really want it.

@travisneilson

This comment has been minimized.

Show comment
Hide comment
@travisneilson

travisneilson Jul 7, 2014

I would appreciate it. But don't do out of your way for only me. Though I can't be the only one that would consider it helpful.

(And I would mention it/you on my YouTube channel :)

travisneilson commented Jul 7, 2014

I would appreciate it. But don't do out of your way for only me. Though I can't be the only one that would consider it helpful.

(And I would mention it/you on my YouTube channel :)

@travisneilson

This comment has been minimized.

Show comment
Hide comment
@travisneilson

travisneilson Jul 7, 2014

Though it's worth mentioning that the desired functionality was potentially accomplished via GRUNT. Though I haven't tested it yet.

Here is the grunt pull request by one of my contributors on our community project: DevTips/Artists-Theme#22

travisneilson commented Jul 7, 2014

Though it's worth mentioning that the desired functionality was potentially accomplished via GRUNT. Though I haven't tested it yet.

Here is the grunt pull request by one of my contributors on our community project: DevTips/Artists-Theme#22

@boodaah

This comment has been minimized.

Show comment
Hide comment
@boodaah

boodaah Jul 7, 2014

I'd like to see the solution @envygeeks brought up. I'm sure the GRUNT solution will work very well, but why install and install node.js and grunt to do what could be done using the jekyll tools we already have. I want to see both options.

boodaah commented Jul 7, 2014

I'd like to see the solution @envygeeks brought up. I'm sure the GRUNT solution will work very well, but why install and install node.js and grunt to do what could be done using the jekyll tools we already have. I want to see both options.

@budparr

This comment has been minimized.

Show comment
Hide comment
@budparr

budparr Jul 7, 2014

Contributor

@envygeeks - my use case was to create a YAML file in the _data folder to give non-technical people access to a set of variables that would interact with the stylesheets (for instance, a color scheme as the easiest example).

However, I've also set up a conveniently located Sass file for users with instructions (e.g. $ prefix), which serves a similar purpose and isn't much more foreign than a YAML file. Or, a YAML file can be used, just not interacting with the stylesheets.

So from my perspective it's a nice to have thing, but not a need to have if adding it falls outside of Jekyll's stated goal of simplicity.

Contributor

budparr commented Jul 7, 2014

@envygeeks - my use case was to create a YAML file in the _data folder to give non-technical people access to a set of variables that would interact with the stylesheets (for instance, a color scheme as the easiest example).

However, I've also set up a conveniently located Sass file for users with instructions (e.g. $ prefix), which serves a similar purpose and isn't much more foreign than a YAML file. Or, a YAML file can be used, just not interacting with the stylesheets.

So from my perspective it's a nice to have thing, but not a need to have if adding it falls outside of Jekyll's stated goal of simplicity.

@imathis

This comment has been minimized.

Show comment
Hide comment
@imathis

imathis Jul 7, 2014

Contributor

I was planning to make use of this in a new theme. I'm glad I never got around to it. I'll think about what it would take to let Sass read from a yaml config, or if that's even a good idea.

Contributor

imathis commented Jul 7, 2014

I was planning to make use of this in a new theme. I'm glad I never got around to it. I'll think about what it would take to let Sass read from a yaml config, or if that's even a good idea.

@travisneilson

This comment has been minimized.

Show comment
Hide comment
@travisneilson

travisneilson Jul 7, 2014

@budparr 's use case is spot on. But I'd argue that having a single place for customization options is the best route, not a .yml for content and a separate .scss for style/colors. If Jekyll wants simplicity, isn't this preferred?

When it comes to theming, (or anything really) you should design for - end user > site owner > site developer

It looks like we are putting the theme developer before the person who would use the theme. 😬

travisneilson commented Jul 7, 2014

@budparr 's use case is spot on. But I'd argue that having a single place for customization options is the best route, not a .yml for content and a separate .scss for style/colors. If Jekyll wants simplicity, isn't this preferred?

When it comes to theming, (or anything really) you should design for - end user > site owner > site developer

It looks like we are putting the theme developer before the person who would use the theme. 😬

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Jul 7, 2014

Contributor

I don't know that the "put this person before another person" argument could even stand up at all under scrutiny because all things considered, this is not Wordpress, you do not have a fancy admin panel where all this can be changed... yes porting the principles of easy configuration for your themes is nice, but you could just as easily put that at the top of your sass file and as a variable and they could just as easily change it there.

I am still for the configuration being available via sass/less/scss (and if @imathis doesn't do it or doesn't want to do it, I will) but the supporting comment, doesn't even fly in my book, because logically it makes no sense to me based on the way Jekyll works and the way they will have to use it in the first place.

Contributor

envygeeks commented Jul 7, 2014

I don't know that the "put this person before another person" argument could even stand up at all under scrutiny because all things considered, this is not Wordpress, you do not have a fancy admin panel where all this can be changed... yes porting the principles of easy configuration for your themes is nice, but you could just as easily put that at the top of your sass file and as a variable and they could just as easily change it there.

I am still for the configuration being available via sass/less/scss (and if @imathis doesn't do it or doesn't want to do it, I will) but the supporting comment, doesn't even fly in my book, because logically it makes no sense to me based on the way Jekyll works and the way they will have to use it in the first place.

@travisneilson

This comment has been minimized.

Show comment
Hide comment
@travisneilson

travisneilson Jul 7, 2014

@envygeeks I see your point, and I accept it.

travisneilson commented Jul 7, 2014

@envygeeks I see your point, and I accept it.

@D-side

This comment has been minimized.

Show comment
Hide comment
@D-side

D-side Jul 28, 2014

I was using variables in my styles too and spent quite some time figuring out what got broken after the update. Turns out, this was actually an intended change, huh.
Too bad. I'd love to see an example of this causing undesired behaviour, but curly braces are widely used pieces of syntax, they'd be hit one day anyway. Sass should be good enough all by itself.

So, after all, I'll have to make something like settings.sass, to keep things customizable.

  • To support that point - styles should be adjusted in style files (*.sass, *.scss), that makes sense, things stay intuitive.
  • Downside - styles cannot reflect anything based on data in site object, that would require writing styles inside HTML tags. Never needed this so far, it's just a point to consider.

D-side commented Jul 28, 2014

I was using variables in my styles too and spent quite some time figuring out what got broken after the update. Turns out, this was actually an intended change, huh.
Too bad. I'd love to see an example of this causing undesired behaviour, but curly braces are widely used pieces of syntax, they'd be hit one day anyway. Sass should be good enough all by itself.

So, after all, I'll have to make something like settings.sass, to keep things customizable.

  • To support that point - styles should be adjusted in style files (*.sass, *.scss), that makes sense, things stay intuitive.
  • Downside - styles cannot reflect anything based on data in site object, that would require writing styles inside HTML tags. Never needed this so far, it's just a point to consider.
@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Jul 28, 2014

Member

@D-side We also wanted to encourage the use of Sass variables in Sass files. Liquid is a bit more powerful but it makes sense to separate domains for now.

We should add a deprecation message though.

Member

parkr commented Jul 28, 2014

@D-side We also wanted to encourage the use of Sass variables in Sass files. Liquid is a bit more powerful but it makes sense to separate domains for now.

We should add a deprecation message though.

@travisneilson

This comment has been minimized.

Show comment
Hide comment
@travisneilson

travisneilson Jul 28, 2014

What is the philosophical basis for wanting the sass variables in sass?

That deprecation message would be helpful!

travisneilson commented Jul 28, 2014

What is the philosophical basis for wanting the sass variables in sass?

That deprecation message would be helpful!

@imathis

This comment has been minimized.

Show comment
Hide comment
@imathis

imathis Jul 29, 2014

Contributor

I don't think there is a problem with processing Sass through liquid, but there is a problem processing everything, especially Javascript and Coffeescript. There are a number of potential issues with Javascript templating languages which use the same or a similar syntax to Liquid. All in all, this becomes a burden to Jekyll to figure out which languages it can process and which will have collisions. Something that may seem safe at first, may become unsafe when used with a particular plugin or framework that collides with Liquid. It's better for Jekyll to say "no" to this, and let the community figure out ways to solve the problems this would have addressed.

I know it's not done yet, but when Octopress Ink ships, any plugin built on Ink will have its stylesheets interpreted through Liquid. This will allow theme and plugin creators to set default configurations and read from user configurations when processing Sass files, and essentially provides this feature to developers. It won't process Coffeescript or any user stylesheets through Liquid.

Contributor

imathis commented Jul 29, 2014

I don't think there is a problem with processing Sass through liquid, but there is a problem processing everything, especially Javascript and Coffeescript. There are a number of potential issues with Javascript templating languages which use the same or a similar syntax to Liquid. All in all, this becomes a burden to Jekyll to figure out which languages it can process and which will have collisions. Something that may seem safe at first, may become unsafe when used with a particular plugin or framework that collides with Liquid. It's better for Jekyll to say "no" to this, and let the community figure out ways to solve the problems this would have addressed.

I know it's not done yet, but when Octopress Ink ships, any plugin built on Ink will have its stylesheets interpreted through Liquid. This will allow theme and plugin creators to set default configurations and read from user configurations when processing Sass files, and essentially provides this feature to developers. It won't process Coffeescript or any user stylesheets through Liquid.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Jul 29, 2014

Member

Alright, I can see the benefit to passing Sass through Liquid. Just note that the process is:

  1. Convert Sass/SCSS to CSS
  2. Render CSS in Liquid

This is how it was before.

Member

parkr commented Jul 29, 2014

Alright, I can see the benefit to passing Sass through Liquid. Just note that the process is:

  1. Convert Sass/SCSS to CSS
  2. Render CSS in Liquid

This is how it was before.

@imathis

This comment has been minimized.

Show comment
Hide comment
@imathis

imathis Jul 29, 2014

Contributor

Hmm. I'm actually processing it with Liquid first, then with Sass. This way I can do stuff like:

{% if theme.dark %}
@import "themes/dark";
{% else %}
@import "themes/light";
{% endif %}

Which is far more powerful than the other way.

Contributor

imathis commented Jul 29, 2014

Hmm. I'm actually processing it with Liquid first, then with Sass. This way I can do stuff like:

{% if theme.dark %}
@import "themes/dark";
{% else %}
@import "themes/light";
{% endif %}

Which is far more powerful than the other way.

@robstarbuck

This comment has been minimized.

Show comment
Hide comment
@robstarbuck

robstarbuck Jul 8, 2015

I've found I can access front-matter by including it in an include:

$brightColor:{{ page.fillcolour }};

And then including that include in my scss file.

{% include sassinclude.scss %}

robstarbuck commented Jul 8, 2015

I've found I can access front-matter by including it in an include:

$brightColor:{{ page.fillcolour }};

And then including that include in my scss file.

{% include sassinclude.scss %}

@jekyll jekyll locked and limited conversation to collaborators Jul 8, 2015

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