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.
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.
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.
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).
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.
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).
@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).