Documentation around whitespace guidance, and philosophy in templates and shortcodes?

I’ve seen a lot of different styles and idiomatic spacing practices within hugo templates and shortcodes… and have seen conflicting opinions on the legitimacy of this way or that way…

Is there an agreed upon practice/philosophy wrt spacing that doesn’t result in the raw pages filled with egregious quantities of whitespace?

I’m assuming there is (perhaps was is more apt in some cases) legitimate reasoning for a lot of these practices… but I’m not keen to just blindly replicate patterns others are using without understanding the guiding logic behind the behavior… however I’ve not found a great explanation of the why…

I understand there’s multiple things at play, and that it’s not a straight-forward thing to answer, but I’m hoping someone could point me in the direction of a clue :slight_smile:

If your shortcodes, partial, or markdown render hooks produce inline HTML elements, you don’t want any extraneous whitespace before or after the element, so something like:

{{- foo }}
{{- foo }}
{{- foo }}
{{- foo }}
{{- foo }}
{{- foo }}
{{- /* this chomps the trailing new line*/ -}}

Otherwise I really don’t care because… --minify.


--minify is… uh… well… kinda being lazy, right?

it feels like 'oh, because minify will prune whitespace, I


a b o u t


I format

because something

fixes it for me

after the fact. and so the formatting becomes the wild-wild-west of different spacings and weird non-intuitive breakpoints, indentations,
and such… and it feels like there’s some legitimate reasons for some of the behaviors

for example, I can see someone making an argument that having any line which contains an html class declaration being isolated to make it easier for css parsers to identify resources’ classes … but that’s no longer REALLY necessary thanks to the stats json blob.

most often I see the spacing weirdness occur {{ if something }}{{ some small blob of emitted content }}
{{ else }}{{ some other blob of emitted content }}{{end}}
around template evaluations
and what seems like an affinity for avoiding multiple template evaluations on one line.

but I dunno how much of this is legitimately useful, and how much of it is simply habit, or legacy behavior that there’s no real downside to doing because some nanny process cleans up after one’s poor spacing consistency :wink:

I spoze this is partially a question of standardization of practices, as well as wondering where the line is between ‘use exterior paint on exterior surfaces’ and ‘use this red paint’

if that makes sense?

No, it is not.

Or, if lazy means efficient use of time, then yes.

1 Like

Fair… and I’m not arguing the benefit of it.

but my question is more driven by a desire to understand what problems manifest and when.

for example, I’ve found that if a shortcode or partial emits (some unit of whitespace) before its’ content,
one can use that shortcode/partial back-to-back-to-back without any undesired extraneous html artifacts being emitted… however if one shortcode or partial emits a single space before its’ content, and another emits multiple spaces, or no space before its’ content then the diverging rendered component is enclosed with html paragraph elements, which is often undesirable.

hence I was wondering if there was some general practice of having say, templates emit a single space, partials emit two, and shortcodes three, or something that I just didn’t grok the nuance of…

I saw hugo --minify puts everything in a single line, making the code hard to read.

Read where? If you look at it in the browser’s developer tools, it is perfectly readable. And I don’t really know why I’d want to read it elsewhere.
Also, many people tend to use -minifiy only in production, not in development.

What you see in the developer tools could be different from your original source, as the browser shows you the interpreted (and formatted) HTML. To see the original source code you need to press CTRL+U. This is helpful to assess HTML well-formedness.

To check that, I’d rather paste the code (with or without whitespace) into one of the HTML validators. A lot faster and more reliable than checking well-formedness manually.

Source code ctrl+u.

That’s what I implied. Didn’t you read my comment?

It’s my preference to avoid conflating opinion/preference with intentional action.

Is there anyplace where there’s some canonical guidance on the nuance of whitespace within html templates/partials/shortcodes, that is current and accurate?

THUS FAR, the main thing I’ve noticed is that there’s a WHOLE LOT of differing opinions on how to use whitespace and go-template-whitespace-chompers.

chomping whitespace can be problematic for a few different reasons, as I understand it.

if I have a few shortcodes…

one ends with a newline-whitespace,
we’ll call him… whitenoise-end.html

{{ /* layouts/shortcodes/whitenoise-end.html */            }}
{{ /* whitenoise-end. I'm noisy. What? */                  }}
{{ /* pretend the following is literally " " and a CRLF */ }}

and we’d invoke him in MD as:
{{< whitenoise-end >}}

and one begins with a chomp…

{{-  $myName := "chompyMcShortcode"                             }} 
{{   /* layouts/shortcodes/chompy-mc-shortcode.html */          }}
{{   /*  I'm chompy. What? I'm a nervous eater. don't judge. */ }}

and he’d be invoked by
{{< chompy-mc-shortcode >}}

also, we have one that ends with a chomp…

{{   $myName := "greedyChompChomp"                              }} 
{{   /* layouts/shortcodes/greedy-chomper.html               */ }}
{{   /*  I'm chompy.... You gonna eat that? I'm hungry      */ -}}

identified as {{< greedy-chomper >}}

if, in a page, I have:

{{< whitenoise-end >}}
{{< chompy-mc-shortcode >}}

is the expectation that I would have, as the resultant html:


should behavior be different if it were invoked like:


{{< whitenoise-end >}}{{< chompy-mc-shortcode >}}


likewise, if I have:

{{< greedy-chomper >}}
{{< whitenoise-end >}}


{{< greedy-chomper >}}{{< whitenoise-end >}}

is the expectation that the resulting html should have:


because chompy-mc-shortcode / greedy-chomper aren’t supposed to be able to chomp beyond their boundaries?

or is chompy expected to be able to chomp until the end of the last html element or non-whitespace/newline?

another way of wording it:

Does whitespace ownership begin/end at instantiation of the thing doing the chomping? or the thing invoking the chomping-template?

Does a partial invoking other partials behave the same? or are there other governing rules?

this is sorta what I’m trying to find explanations on… as there’s a lot of moving pieces in play, and I’m not sure what EXPECTED behavior is… or where that expectation is expressed in clear english… y’know?

I got lost in a rabbithole of yakshavers looking at the hugo source code, and don’t think that’ll be much help for me right now…