Open denis-sokolov opened 9 years ago
I like the approach of making the inliner do as much of the leg work for you (allowing you to opt out when it makes sense), so I think it makes sense to use the html-minifier as a module to compress the output.
My only slight concern is aggressive compression on HTML can result on a different visual representation of the markup (ie. I'd want to use the conservativeCollapse
flag for instance to ensure spaces remained intact).
I'd be open to a PR if you wanted a shot at it (please check out the contributing doc as it helps with tests and commits).
I like the approach of making the inliner do as much of the leg work for you (allowing you to opt out when it makes sense), so I think it makes sense to use the html-minifier as a module to compress the output.
Sure! Some projects at some point choose to spin-off a module (say, inliner-lib
) that only contains the minimum core logic and make the primary module depend on that and wrap it with more extra functionality. I suggest to keep this possibility in mind if you notice at some point such a need.
My only slight concern is aggressive compression on HTML can result on a different visual representation of the markup (ie. I'd want to use the conservativeCollapse flag for instance to ensure spaces remained intact).
Well, yes. The point is, your current compression on HTML already results in a different visual representation of the markup. As I mentioned in the original issue, for example, you change the visual representation of a placeholder
attribute for a textarea
, a visual representation for ~~s~~
and others.
Minifying html is pretty hard to do for a general case. In particular, any element may have a white-space: pre
specified in CSS. Thus it's important to allow disabling and possibly customize the minification process. If you keep HTML minification as part of the module, I'd suggest exposing the ability to pass options to html minifier.
I can't make any promises about PRs though, but maybe.
:+1: for html-minifier with "conservative"/non-agressive options :smile:
+1
I also have the issue when I include JS minified code: when the collapseWhitespace
option is enabled, it breaks the JS code. The html minification should really be done by a separate proven package, such as htmlmin for example.
It would also be nice if the minifier options for html/css/js could be further customized by passing through arguments directly to the minifier (I also have issues with uglifyjs default options, and there's no way to override them). This way everyone should be happy 😁
Folks, remember, if you want this feature, either use the native 👍 or include a real test or use case, or even better: a PR.
I've not personally hit this issue at all, so I've no real motivation to work on it myself (that's not to say others aren't hitting the issue).
I'm generally deleting github issues with just +1
in them these days.
Currently the HTML minification in this module is far from perfect. It treats
pre
andtextarea
specially, but not other cases, such as newlines intextarea
placeholder
attributes or elsewhere. It corrupts strings of~~s~~
in the source code and further.Perhaps instead of this manual processing step using a 3rd party tool, such as a popular html-minifier would be warranted? As a matter of fact, that tool can also minify inlined css and js.
As a matter of fact, perhaps it would be valuable to keep the tool minimal and suggests users to use
html-minifier
on the output themselves, keeping the current tool focused on inlining more interesting resources?