`hugo --minify` strips out `</p>` tags

[zwbetz]

Hello there. First off, thanks to all of you who contribute to this project. I really enjoy using hugo, and use it to build my personal site.

So I just upgraded to version 0.47.1 and wanted to test out the hugo --minify command. In my testing, I noticed that the command stripped out my </p> tags (see my examples below). Was just wondering if that was intended behavior?

Output of hugo env

Hugo Static Site Generator v0.47.1 windows/386 BuildDate: 2018-08-20T08:17:27Z
GOOS="windows"
GOARCH="386"
GOVERSION="go1.10.3"

The relevant html after running hugo

<p>
    <a href="/2018/03/things-i-like/">Things I like</a>
    <small class="text-muted">
        2018-03-21
    </small>
</p>

<p>
    <a href="/2018/03/aliases-in-windows-command-prompt/">Aliases in Windows Command Prompt</a>
    <small class="text-muted">
        2018-03-13
    </small>
</p>

<p>
    <a href="/2018/03/simple-pleasures/">Simple pleasures</a>
    <small class="text-muted">
        2018-03-09
    </small>
</p>

The relevant html after running hugo --minify

<p><a href=/2018/03/things-i-like/>Things I like</a>
<small class=text-muted>2018-03-21</small><p><a href=/2018/03/aliases-in-windows-command-prompt/>Aliases in Windows Command Prompt</a>
<small class=text-muted>2018-03-13</small><p><a href=/2018/03/simple-pleasures/>Simple pleasures</a>
<small class=text-muted>2018-03-09</small>

[maiki]

@zwbetz

Was just wondering if that was intended behavior?

I doubt that was the intended behavior. We have to see your site’s code to see why that is happening. Please check out Requesting Help and share some code.

[zwbetz]

My site is in a private BitBucket repository, but I can make it public temporarily for this.

https://bitbucket.org/zwbetz/zwbetz/src/master/

[bep]

I suspect this is another of those “over eager” default settings of the minifier we use. Create an issue on GH and we will … hopefully fix it.

[zwbetz]

Thanks @bep. I’ll open a GitHub issue.

Okay, marking my site repo as private again, I’ll post the relevant code in the GH issue.

[zwbetz]

For reference, GitHub issue link: https://github.com/gohugoio/hugo/issues/5112

[alexandros]

Issue closed and the fix will be available in the next Hugo release.

Also if you see anything else stripped by the minifier please let us know.

So far there have been a couple of similar issues, because the default configuration of the minifier from upstream is a bit aggressive and additional flags need to be added manually.

Thanks!

[kaushalmodi]

@zwbetz What was the problem caused by the removal of the closing p tags?

Many closing tags are optional in HTML5 if removing those causes 0 ambiguity. See http://blog.teamtreehouse.com/to-close-or-not-to-close-tags-in-html5.

So removing those closing tags is a smart optimization.

I’d bet that your site still behaves functionally well without those closing tags.

@bep I’d suggest reverting this commit, if re-adding the closing tags is just cosmetic. This is a minify feature that does some good cruft cutting (it not removing only optional closing p tags, it’s much more).

[bep]

@kaushalmodi

So removing those closing tags is a smart optimization.

I’m on the fence on this. I think the current setting is good as a default.

[kaushalmodi]

It’s like saying “I want to minify, but don’t do it as best as you can”

What’s the advantage of keeping the redundant closing tags if the browsers don’t care about those? Why would a human need to read a minified HTML?

[bep]

What is the browser test coverage for the “stripped tags” option? And I don’t mean your “Chrome seem to be fine with it” kind of tests. A complete test suite.

[zwbetz]

@kaushalmodi since reading the to close or not to close tags link you posted, I’ve deployed my site with the --minify flag, and tested in:

• IE 11
• Chrome 68
• Firefox 61
• Safari in iOS 11.4.1

So far, it appears to be fine.

[kaushalmodi]

Thanks for testing. I am not surprised.

I have been minifying my site with the same library for more than 6 months (i.e. even before it got integrated with Hugo via the --minify switch) and I didn’t use this “don’t remove end tags” option – I’ve never faced any issue.

[Yudy_Ananda]

Hi all

sorry if I’m interupting here…

Just want to share same experience with hugo --minify but in my case it strips out </li>

before minify

<li class="social-facebook-li social-li">
	<a class=social-share title="Bagikan ke Facebook">
		<div class="share-fb-bg share-icon-bg"><svg aria-label="Facebook Share" class="share-fb-icon share-icon">
			<use xlink:href="#share-facebook"/></svg>
		</div>
		<div class=social-share-label>
			<div class="network-label has-text-weight-bold has-text-left noselect">share</div>
		</div>
		<span class=label-overlay></span>
	</a>
</li>

after hugo --minify

<li class="social-facebook-li social-li">
	<a class=social-share title="Bagikan ke Facebook">
		<div class="share-fb-bg share-icon-bg"><svg aria-label="Facebook Share" class="share-fb-icon share-icon">
			<use xlink:href="#share-facebook"/></svg>
		</div>
		<div class=social-share-label>
			<div class="network-label has-text-weight-bold has-text-left noselect">share</div>
		</div>
		<span class=label-overlay></span>
	</a>

tested with

• Firefox 61.0.2
• Chrome 68

the browser can read the li (if i inspect the element the li have the closing tag) the problems is with the appereance (style ) of the li element

here is the screenshot

so in this case I have to anticipate the style for --minify version

thank you guys

[kaushalmodi]

To be honest, the one on the right looks correct. Can you share the site source that has that white space between elements?

Here the white space on the left (before minify) most likely has nothing to do with absence/presence of end tags. But I’d like to inspect that element and see what’s adding that white space.

If you want to add such space between elements, I think the CSS padding/margin properties should be used.

[Yudy_Ananda]

Hi again

updated

this are build without --minify

• case 1
• case 2

the build with hugo --minify

• case 1
• case 2

case 2 where closing li strips out is located near the author field, the text is baca di become bacadi

i forgot to mention found that line inside tag and attribute not minified, not sure if this one is should be include in minify feature

@kaushalmodi

If you want to add such space between elements, I think the CSS padding/margin properties should be used.

yes I also consider to do that, at least for now, thank you

[alexandros]

@Yudy_Ananda

case 2 where closing li strips out is located near the author field, the text is baca di become bacadi

The li elements have closing tags when I inspect your page with the Dev Tools in Firefox.

You need to have padding or margin set between these elements or if it is a phrase a space after the first li should do, so that a search engine could read that phrase properly.

[Yudy_Ananda]

@kaushalmodi

It’s like saying “I want to minify, but don’t do it as best as you can”

make sense Ok,I realize this is not --minify issue

thank you for the sugestion, seems that I have to consider using space or padding as You and @kaushalmodi mention

[zwbetz]

To clarify, Chrome (and Firefox) Dev Tools adds the closing tag(s) back in.

When viewing the HTML with Right-click > View page source the closing tags are stripped, as expected.

[bep]

To me:

• HTML minification is mostly about removing whitespace.
• Browsers are mostly lenient vs end tags etc.
• But there may be browsers/http clients/web crawlers etc. out there that isn’t
• So, I’m not sure the saving of some “” is worth it…
• We will eventually get some config support for this …