How to use Hugo Template variables in CSS!

So far the only thing I’ve been able to come up with is how I featured Dynamic Google fonts in hugo templates

If you put any code in the CSS file, it gets rendered as just that:

.css file
p {
font-name: {{ .Site.Params.fontparagraph }}

But is there any better way to actually put hugo template codes in the actual .css files? I would love to get deeper into GoLang and would love to learn how to write a patch for Hugo that would allow:

  1. You can normally use CSS files, just pure CSS as it has always been, no problem. *.css files.

  2. Introduce .hcss files which are regular CSS files but inside of them {{ }} template code can be parsed.


Parse regular .css files for Hugo template variables.

Now if people want to use normal CSS, they can do that. Or if they want to include some template variables, they can do that.

Ideas? Opinions? Thoughts?

EDIT 11/3/2016 12:52pm: - It’s published here now. Enjoy.

1 Like

I submitted a pull request to fix this problem. A config option would enable Hugo to parse all CSS files in the static directory as a Hugo template. Inside the config file you can added arbitrary values to the Params block which can be accessed through the context in the stylesheets.

This PR is more or less in a WIP state since it’s only a small part in the bigger picture of upcoming enhancements and design decisions in Hugo.

1 Like

Using Hugo to modify CSS files sounds rather like a dirty hack.
I’d rather recommend tools like gulp, grunt, prepros for processing.

And how would they have access to hugo template variables?

Thank you very much, sir. I shall surely look into this deeper.

Not at all, because HTML and CSS are imho 2 different things :slightly_smiling:

Do you have to change the font that often … but you never touch your CSS?

If you touch your CSS, what sense does it make to maintain the webfont in the config.toml.

I don’t think I said it right, or maybe you don’t understand, maybe I lack articulation.

  • I’m trying to access hugo .Site and .Params etc. variables inside CSS files.
  • It’s not just for fonts.
  • It works just like template files. You define variables in the config, you access them in the .html template files. Same thing for CSS files.

I’m unsure how else to say this. I feel like you want to be more sarcastic or critical instead of trying to understand. The problem with communication in the world is that most of us don’t listen to understand, we listen to judge and argue and show off what we know in our minds. This social posturing and strutting is real turn off.

Ok, well I’m sorry. I understood you right.

I was just irritated that somebody is trying to do that at all, because it doesn’t feel right.

But maybe it’s the right solution for your requirements.

Why are you irritated? And even if you are, it’s not a good idea to showcase that to the world. Anyway. I’ll look into the Github issue. Until then I know how to get my work done. Thank you.

In the current implementation the template is neither a node nor a page. Hence you don’t have access to any of this information. But it’s a good point that should be considered. Thefore, the PR is still in a WIP state and it’s likely that some decision decisions will be changed or withdrawn.

Yessir, that I totally understand.

My question was directed at ITSecMedia in response to CSS pre-processors. By “they” I was referring to the pre-processors the gentleman mentioned.

I’m still in need to go through the actual Hugo code to see how things really work. :slightly_smiling:

I’m going to wholeheartedly agree with @ITSecMedia on this one. Hugo is awesome at content. I dig the hack that @Hash_Borgir put together for easily switching out Google fonts, but that’s still a pretty bad practice in terms of creating scalable, manageable CSS. The Gulp and Node.js ecosystem is extraordinarily vast in terms of these asset pipelines. If you want to create a ton of variables that can be adjusted by someone with minimal front-end development expertise, I’d recommend building your CSS in a preprocessor, since all of them have the ability to do this…

1 Like

The gentleman made a superb suggestion. I observe many things within my own psychological field. Though CSS pre-processors are fantastic for many reasons, I wanted to try to keep configuration to a minimum. I am fully unopposed to using CSS pre-processors.

I’ve experienced the layers of complexity in some workflows introduced by CSS pre-processors and I was hoping to avoid that in something as simple as a blog. I didn’t really need the complexity of all that.

I have observed that sometimes simple hacks go a long way, more so than what most would consider the “proper” way. Are they scalable? :slightly_smiling:

If we could have Hugo parse CSS files for Hugo variables, there goes the need to have pre-processors. One could still employ them if one desired.

The reason why I did the Google font switching hack (to make it easy) is that I found myself modifying fonts a lot because I found myself testing out all sorts of font combinations. I’m a programmer who is now learning web-dev and design and all that. I’m noob! :smiley: .

There are many other things in my mind, for which I don’t really need a full pre-processor for this. I employ them elsewhere, sure.

Thank you very much for your reply.

1 Like

For example, one could create layouts/partials/hugo_css.html with the following contents for example:

    body { 
         font-family: {{ }}; 

and call this from partials/head.html, right above the closing </head> tag.

{{ partial "hugo_css.html" . }}

And now one can easily use Hugo template vars/data etc. inside CSS. It’s an ugly hack, but I like hacking. Where is the fun in going along with the masses, eh? :slightly_smiling:

“Non-conformity is the true core of self-reliance.” - Hash Borgir

If I feel the need is great enough, I’ll end up with CSS pre-processors in my blog too! :smiley:

Thank you.

EDIT: Better organization maybe like so: /partials/css/filename.css.html (whatever you want)

1 Like

@Hash_Borgir Like I said, I dig the hack…and sometimes configuration can be a very handy thing. I did something similar with inlining CSS background-image: for article heros in a site I built for my team.

Unfortunately, this is not the case for many reasons—the most obvious of which is the fact that if Hugo runs through your CSS as part of your build, then HUGO becomes a preprocesssor. :wink: You’ll have to look into the docs for popular projects—eg, here and here—since preprocessing is about a lot more than just variables.

Additionally, variables in a preprocessor will be formatted differently from variables in Golang templates. So throwing in $ (used in, say, SASS) with templating syntax that is not part of a preprocessor will likely make those builds break. For example, if you’re running something like gulp-sass during dev. If you want to include preprocessing as part of Hugo, you’re talking about adding a Golang-based binding for something like libsass. But then you inherit all the related support issues, and it also assumes, in this example, that SASS is the best preprocessor to choose…as opposed to Stylus, PostCSS, blah, blah, blah.

This isn’t a knock. I might use your Google Fonts idea in the next site I build :slightly_smiling:

1 Like

I do not fully understand CSS pre-processors to the degree some others do here and I’d rather not make any statements as that would be pre-mature/immature.

I’ve used them. I’ve utilized them. I have not taken the time to understand them. I shall attempt that soon and let us hope the understanding follows suit. :slightly_smiling:

Sir, I am quite unhurt even if one were to criticize or knock something I’ve built. It really is the only way to learn, however, the sentiment showcased was not criticism out of love, but out of personal aggravation, which completely changed the psychological underpinnings of the entire thought process. I hope I didn’t say anything to anyone that might have been out of line. See, I don’t judge and/or condemn. One simply cannot understand or observe what one has judged or condemned. I speak freely, and that has a tendency to … not sit right with some. I sincerely believe that being human, Human Beings; we love and cherish one another. Therefore we can simply focus on being honest and truthful. Criticism born of love in order to better has a totally different delivery than criticism born of personal frustration. Without going off-topic into philosophy… Welp. There it is. :slightly_smiling:

Let us move on to better things.

I just wanted a quick way to use Hugo vars in CSS w/o relying on other layers of complexity. That’s all. I found a way. For now. :slightly_smiling:

1 Like

It’s here now.

1 Like

@rdwatters I actually stumbled upon this thread in search of adding some dynamic CSS to my index.html for adding the background-image property to a list of divs on the front page of my site. Do you mind sharing what configuration you came up with?

Currently our site has content type chapter and index.html shows a list of chapters. Each chapter has a URL to an image in their front matter “background_image”. I want to do something like this in the template:

<div class="chapterList">

    {{ range where .Data.Pages "Section" "chapter" }}

    <div class="chapter chapter{{ .Params.chapter}}" style="background-image: {{ .Params.background_image }}; height: 100%; ">
        <h2><a href="{{ .URL }}">{{ .Params.chapter }}: {{ .Title }}</a></h2>


Everything works except for the dynamic templating in the CSS. Not sure how to get around that.

@kjrhody Can you point me to a repo or at least provide some more context?

Are you keeping all your images in the same place within static? For example, static/images?

Also, what doesn’t work specifically? Is it that you’re getting random characters in place of the image url (i.e., Golang templates are escaping your CSS as “unsafe”) or is it that you can’t get it to point to the right image?

@rdwatters Ah sorry… appears that my CSS syntax was incorrect… should have been

style="background-image: url({{ .Params.background_image }});

That works just fine.

Without the url() to enclose it, it was showing:

<div class="chapter chapter1" style="background-image: ZgotmplZ; height: 100%; ">

1 Like