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


#22

I suspect the space between your buttons is not caused by the </li> but by the whitespace in the file. Try removing the whitespace but leaving the closing tag and see if that also causes the margins to be wrong.

FWIW, I am also struggling with this issue for a site I inherited the CSS for, which was dependent on whitespace preventing element collapse in different places. Basically, I consider those things bugs, but it does lead to some problems.


#23

I just wanted to clarify that removing end tags is intended behavior. HTML5 is not XML, and these end tags (and some start tags) are very clearly defined in the specifications as optional and thus not required. This will never affect the way your HTML5 is displayed anywhere.

The problem encountered by @Yudy_Ananda is because of the whitespace removal. You’ve made the <div> elements an inline element, and you rely on whitespace to separate the two divs. This is covered in the Readme, but I would say it is not a good idea to rely on whitespace between elements in the first place. I’ve made an issue anyways https://github.com/tdewolff/minify/issues/224 to investigate the problem properly when I have more time.


#24

There hasn’t been a true bug report so far that demonstrated issues due to missing optional end tags.

The original bug report was just “crying out wolf”. The bug reporter didn’t find any functional failures… he just got surprised seeing missing end tags.

The other report is due to bad practice of relying on white space in HTML (which would get removed due to minification with or without end tags); CSS should havd been used there.

I still think that that commit should be reverted.


#25

This is as simple as this:

  1. I don’t want the minifier to strip any end tags from my sites.
  2. Many have expressed concerns about the same. You seem to be in minority. But even if you were not, see 1)
  3. I will assume that keeping these tags is more compatible than not
  4. Saving some bytes isn’t worth it
  5. We will eventually get some config settings for these to make all happy
  6. We are not reverting that commit

#26

I’m not sure how the most recent browser versions cope with it, but in the past it caused problems with CSS if end tags were missing (optional or not).


#27

I found the built in minifier is stripping the type=“text” attribute from input tags when building using V0.48

I’ve raised an issue on GitHub with relevant info


Bug in minify (hugo 0.48)
#28

I suppose that this could be fixed if the --html-keep-default-attrvals flag is enabled.

However I’m not 100% sure, if that is the correct flag. See here

Out of curiosity what is your CSS rule for <input type="text">?

If it’s the generic one i.e. input[type="text"] did you try assigning a class to these input fields and targeting them like that?

I don’t think that class attributes are stripped with the current flags of the minifier.

At some point there will be options in the config for this.


#29

@onedrawingperday

The site is built on Foundation, which by default applies styles (based on SCSS settings) to inputs based on their attribute type ie input[type="text"], not a class. I think from memory Bootstrap does the same, but it’s been ages since I’ve used that framework.

As a fallback we could apply these styles via a class, but seeing as the two major frontend frameworks attach styles via the type attribute, it would be nice if these tags could not be stripped out.

Further testing results…

I’ve tested my source on the online minifier demo for the minifier Hugo uses and when passing the flag --html-keep-default-attrval the input[type="text"] attribute is not stripped out. Removing the flag --html-keep-default-attrval does indeed strip the input[type="text"] attribute.

It looks like --html-keep-default-attrval is the correct flag to enable.

Link below if you want to test

https://go.tacodewolff.nl/minify


#30

I don’t use these frameworks, therefore I don’t know how they’ve structured their CSS rules.

Also I commented on the GitHub Issue that --html-keep-default-attrvals is indeed the flag that needs to be added to fix this problem (after your confirmation above).


#31

Many thanks, appreciated :+1:.


#32

@BinaryJim I think it would be wise to add a bug report with the CSS frameworks, as they seem to not be fully compliant with HTML5 specification. To apply a style to text input elements, one needs to use the CSS selector that selects both inputs with type=text and inputs with no text attribute, as they both generate the exact same element. The CSS selector needs to be something like input[type=text], input:not([type]) { ... }

The option KeepDefaultAttrVals is indeed intended to support CSS frameworks that are not fully HTML5 compliant. On the otherhand, end-tag removal has nothing to do with CSS and should never affect the looks (aside from reliance on whitespace).


#33

KeepDefaultAttrVals was added in commit 9b26b5487b5c5142fe9fb58681fe7d1dac95a291

This thread is long. If something else comes up feel free to report in another topic.


#34