Issues with Template Parsing: HTML element opening/closing tags misread as HTML entities in several situations

I’ve narrowed down the issue, and it seems like it might relate to two other issues I’ve encountered before regarding how Hugo handles single <s and >s. Here is the MRE (run hugo serve and go to [your localhost]/test to view the example).


This particular issue is because the HTML tag is closed by a sole > on a new line, which the parser reads as Markdown blockquote syntax.

This can be worked around by using a no-op template construct (such as {{- /**/ -}}, per your example elsewhere), but for some reason that construct throws the following error if either of the -s is missing (e.g., {{ /**/ -}}):

parse failed unexpected “/” in command

If I really need the spacing on one side I can use a longer construct (e.g., {{ if 1 -}}{{- /**/ -}}{{ end -}}), but this makes my templates pretty messy.

But, without knowing the details of how the parsing algorithm works, I would have expected the parser should already be in ‘HTML element’ mode because it will have already hit the opening tag, so it should be anticipating a closing > and not be reading it (new line or not) as an unrelated symbol. So this seems to be a bug, though I don’t know if it’s a Hugo, Goldmark or Go issue.


The other two issues seem to be because the parser struggles with < on their own, or immediately followed by {{, which both result in an &lt; instead of a <.

This means you can’t seem to have conditional element names within a single tag (as opposed to conditional tags; see layouts/shortcodes/foo.html). It does render the correct names, but within &lt; and &gt; elements rather than as HTML elements.

It also means you get misrendered comment blocks (see layouts/partials/copying.html). This doesn’t seem to have anything to do with Markdown, as it happens the same when I include the copyright comment block partial directly in the head of my page template. This issue also only replaces the opening < with &lt;, leaving the closing > as it is.


FWIW having spacing between the name of an element and its closing > seems standards-compliant, and whilst having a space between the opening < and the element name isn’t, in foo.html you can see that I’ve used -s to remove all whitespace.