This isn't HTML-language issue, so filing a bug report for it here isn't a very good way at all to get consideration for it. Plus, it's not clear what type of minification you mean but there is no form of minification for HTML content. It seems much more likely this idea relates to JavaScript minification, in which case you'd rather need to get TC39's attention for it as a new feature for JavaScript.

Regardless, these days the best way to proceed with stuff like this is probably to start a new discussion thread for it at http://discourse.specifiction.org/ (rather then raising a bug or issue report somewhere). That way you can find out whether other webdevs think it's a good idea and whether some browser implementors might have any interest in implementing support for it.

Yes, it is an HTML issue, because the format for comments is in HTML5 section 8.1.6. Google recommended that I speed page loading of my site by minifying my HTML and CSS files; I've never had JavaScript except that supplied by Google, which I think I added to my pages only after their minification recommendation, and their JavaScript includes a comment that presumably should not be removed by minification, yet its format is the same as for most comments.

Minification generally consists of removing whitespace, comments, and other things not necessary for user agents' interpretation of coding. User agents wouldn't do minification. Some other apps would do it.

I'll keep specifiction.org in mind for when I can't figure out which spec is relevant. Thanks.

I don't know whether a string should be inserted into a comment to prevent/discourage minification or if a different comment format altogether would be preferable.

(In reply to Nick Levinson from comment #2)
> Yes, it is an HTML issue, because the format for comments is in HTML5
> section 8.1.6. Google recommended that I speed page loading of my site by
> minifying my HTML and CSS files

So you're voluntarily choosing to remove HTML comments from your own HTML files because Google recommended it? If the HTML language were to define some other type of comment format, I see no reason why the creators of whatever Google guidelines you're looking wouldn't then just recommend that you remove those too. What would prevent them from recommending that? And if they did, would you then follow that recommendation too? Where would it stop?

> Minification generally consists of removing whitespace, comments, and other
> things not necessary for user agents' interpretation of coding. User agents
> wouldn't do minification. Some other apps would do it.

So the solution to the root problem you seem to be trying to work around here is really simple: Don't remove comments from your HTML files if you want your HTML files to have comments. Nobody is forcing you to. You have a choice.

If you're using some tool that automatically removes HTML comments as part of some kind of  HTML "minification" process, then just quit using that tool.

The HTML spec says nothing about "minification" and defines nothing about what is supposed to happen to HTML comments during "minification". Instead it defines a single mechanism for marking up comments. That's it. So there is no value in adding a redundant markup feature to the HTML language to represent something the language already defines. And there is pretty much zero chance of such of a redundant other comment-markup feature ever getting added to HTML.

I can't prevent you from re-opening this bug here but all I can say is that if you do, I think the only thing that's likely to happen is that it's just going to sit open indefinitely with nobody taking any action on it.

I don't view the world as quite that near to black and white and most even mildly competent geeks don't do something just because SomeBody Big and Massively Important Said So. I don't do any minification now, although I also don't write HTML or CSS with massive amounts of whitespace, either. The reason I don't minify is that I want to upload the comments that I have, but some programmers write comments that they don't need to upload, usually comments explaining things about the programming per se. I think the general practice is that one keeps a set of preminification files that can be uploaded to a website and that's what one would edit for content, style, layout, etc., making copies just for minifying and uploading. Minification is being mentioned in various places lately and I can see why it would be beneficial, especially if a page is large and a user's connection is slow (an example of a big page is <http://www.w3.org/TR/html5/single-page.html>, which takes a while to load even on my WiFi laptop, which I accept since I want a single page for searching and I usually do other things while it loads). Google is not being hypocritical, as far as I know; the source code for their search home (https://www.google.com/?gws_rd=ssl as of a few minutes ago) is minified and has no comments. I don't think Google would object to some comments being kept despite minification, since a second comment format or marker would be explicitly for that purpose (it doesn't matter that the purpose wasn't previously addressed in HTML5 since many things are added because technology and practice evolve) and Google's engineers can surely understand an explanation on that point.

I'm reopening, while acknowledging that the priority may get lowered, because I found several implementations of the concept, albeit inconsistent ones. Probably the best format would be this opening tag:

<!--!

To begin the comment content itself with an exclamation point and not a space, the author would write a double exclamation point. Whether to separate the opening tag from the content with a space would be unaffected. The closing tag would be unaffected.

Here are implementations I found, in order of utility for consideration for HTML5:

htmlmin 0.1.6 (thus, by convention, beta): "When set, comments will be removed. They can be kept on an individual basis by starting them with a '!' . . . . The '!' will be removed from the final output. If you want a '!' as the leading character of your comment, put two of them . . . ." https://pypi.python.org/pypi/htmlmin/ & https://github.com/mankyd/htmlmin > "Download ZIP" > htmlmin-master.zip > docs > quickstart.rst > optional arguments > "-c, --remove-comments", both as accessed Aug. 15, 2015.

HTML compressor: Follow the standard comment opening tag by any one user-specified character to preserve that comment (<https://htmlcompressor.com/compressor/> > Source > show > Comments, CSS and JavaScript > "Keep . . ." > "(?)", as accessed Aug. 15, 2015), i.e., the Web page author may specify a character and put it immediately after the opening tag to preserve the comment that has the specified character.

html-minifier (by kangax): "If you have chunks of markup you would like preserved, you can wrap them". Inside the comment would appear the string htmlmin:ignore (but unclear where inside the comment). <https://github.com/kangax/html-minifier>, as accessed July 14, 2015. "[T]here's a slight difference in the way HTML comments are treated inside SCRIPT and STYLE elements. In scripts, comment start delimiter ('<!-<span></span>-') tells parser to ignore everything until newline" <http://perfectionkills.com/experimenting-with-html-minifier/>, as accessed Jul. 15, 2015.

gulp-minify-html can decline to minify "conditional internet explorer comments". <https://www.npmjs.com/package/gulp-minify-html>, as accesssed Jul. 24, 2015.

HTML5.1 Bugzilla Bug Triage: This is invalid for HTML. The minifiers are external tools able to reduce and remove any content they deem necessary. They do this to provide the smallest code possible for transmission while also providing the same functionality. Since comments of any kind do not provide any functional behavior, minifiers strip out any characters that it deems a common pattern of characters that provide no functional use. I would think comments of any format (current or some new format) would in time be stripped out by minifiers since they provide no functional value.

If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!

I have opened there (https://github.com/w3c/html/issues/294). Many comments are programmatically and otherwise functional, and examples can be found on many websites and in much online advice on page authoring and on styling. Nor should minifiers be allowed to strip all comments if authors want some preserved, and many authors want some comments preserved. More is explained there. Thank you.