BEM Layout Options

feature
#1

I have been really enjoying BEM methodology for my CSS these days and have been thinking hard about how to best organize a theme/site with BEM in mind. For starters I have decided to stick with a theme/THEME/layouts/TYPE/block.html view that contains usually one <div class="TYPE"> to match the concept of a block in the BEM methodology. Then in theme/THEME/static/ directory I will have a TYPE.styl that gets compiled as a TYPE.css but also, currently, into main.css where it is required (@require TYPE) in the main.styl file.

Decoupling style workflows from the rest of hugo compiling is something I have always liked. It leaves options. But the idea of having a monolithic CSS file (while highly performant and justified) seems contrary to the idea of being able to override parts of a theme, as is best practice with types and partials. Then there is the question of block-related JavaScript.

What, if any, options are out there to encapsulate blocks in a sort-of bower-meets-hugo sort of way? Would it be even worth considering a theme/THEME/blocks/BLOCK/{html,js,css}? It seems to make more sense keeping it simple rather than dealing with dependency management as bower does. Am I being lured to the left-brain side of things on this or does the BEM approach to web content modularity warrant consideration within the hugo context (such that the template language could be included)? Would there be value perhaps adding a blocks.gohugo.io at some point where reusable blocks could be used in the same sense that go get uses libraries?

I believe much of what is necessary to implement this approach is there already. One key missing piece is combining the separate CSS into a single monolithic one. It seems the concept of overriding a theme partial or type view simply does not carry over to css, which arguably has a more valid need for partial overrides. I understand this can be done now by linking several individual CSS files, but how does this stack up against a single monolithic CSS? Right now it seems most use all or nothing on the big CSS.

Honestly I am just interested in others opinions on this. I do not believe implementing encapsulated blocks in a BEM meets Bower sort of way can currently be accomplished in Hugo without Hugo getting into at least the CSS combinator business. For example, if we had a bunch of theme/THEME/blocks/*/*.css files Hugo would at least need to combine them into one monolith under the equivalent of theme/THEME/static/css/main.css which defeats the idea of static in the first place.

Thanks for any input. For now I will continue (like everyone else) to require those using my theme to override all of theme/THEME/static/css/main.css and recommend they link their own static/css/local.css AFTER the main.css link in layouts/head.html or whatever so that main.css can be changed by the theme author without forcing them to recreate their own entire static/css/main.css file every time the theme is updated. In fact, I think i will included the link to an empty theme/THEME/css/local.css so the placeholder is there for them to simply include static/css/local.css with their own overrides. Feels like there is something better, but that will work for now.

#2

I just wanted a single monolithic css file to reduce calls when loading, so I am building it with gulp. I edit various small css files, combine them with basscss modules loaded via npm. Npm is watching and re-bundling a compressed css, which Hugo then references.

If I needed another bundle for a different part of the site, I’d just make another set of folders for gulp to process, then use the Hugo template to load whichever one as appropriate.

You can see how I structured my Hugo project folder to contain the node project, for what it’s worth, here:

It’s not the end-all or anything, but it’s one idea for you.

#3

I appreciate your response. NPM and make are how I’ve always done my preprocessing as well (and continue to). I suppose the main point is how this seems somehow incompatible with the idea of theme partials, which can be overridden/shadowed by local versions of the same thing. The encouragement to make ‘liberal use of partials’ in themes is the thinking behind this, which I agree with. I just an searching for a similar approach to the CSS portion of the theme. Sort of a way to use CSS partials, for lack of a better word. All the preprocessing happens during site builds, etc, but overriding elements of a theme don’t fit into the preprocessing.

#4

If you’re already involved in this discussion I apologize @robmuh, but here’s a discussion on the roadmap to Hugo 1.0. https://discuss.gohugo.io/t/roadmap-to-hugo-v1-0/2278, that touches on that sort of pre-processing by Hugo itself. I can’t imagine it being as flexible as a gulp, but, at least it will give us another option to work with.

Hugo 1.0 ideas have also been discussed on the Gitter dev forum, so, you might want to chime in there.

My understanding, looking into some tech like webpack or react, is that what you’re describing is how those are set up to work.