While I am known for some truly colorful speech, I've never been wild about those types of comments in code; Particularly in interpreted programming languages...
... and while HTML/CSS are not truly programming languages... Wait, no!!! It's a series of instructions telling the computer what to do -- After 34 years of ADA to ZZT-Oop I'm pretty sure that's what a program is. File that alongside the idiocy of calling XML a machine parse-able data format.
For all intents and purposes HTML and CSS suffer the problems common to interpreted languages; the biggest of which being the size of the program affects performance, making comments flat out being bloat.
So it comes down to a question I had drilled into my head by a nun with a metal ruler (see also why I'm so strict on my indentation)-- how does this comment help the next person who comes along?
In an interpreted language (as opposed to a compiled language) comments should be terse, clear and free of needless banter.
It's also why I object to COMPLETELY IDIOTIC comments like:
<!-- start content -->
No ****, REALLY? Opening a DIV with the ID content is the start of the CONTENT?!? I NEVER WOULD HAVE GUESSED. :rofl:
Then there's how IE and FF can both screw up if comments end up between sibling level elements -- for IE it's for between floats and sometimes between inlines, for FF I've seen it treat comments as block-level depending on what version you're running; and with FF's propensity for code regressions it better to not risk it...
Which is why this type of comment:
</div><!-- end content -->
Is just as silly AND problematic. It being after could put it between sibling tags, and closing a tag means the end of something? Do I have to say it?
... and the 'fix' is so simple, and clear as a bell what's going on...
<!-- #content --></div>
The # tells me I'm talking about an ID just like how you refer to it in CSS, and the tag itself tells me what I'm doing with it.
There's an article on IBM's web developer website I always link to when the subject of comments comes up. It's meant for C programmers but I think coders of all types can come away with something useful.
Six ways to write more comprehensible code
I'm particularly fond of the "Oh, now we're done?" section.
Now, some people will hear "comments are bloat" and automatically start stripping them out just like they do white-space for deployment; It remains my experience that if you have to white-space strip or resort to any extra compression above/beyond what your server should be providing with mod_deflate, that there is something horribly and horrifically wrong with your code in the first place... A few meaningful comments to make it clear what's being closed and point out anything out of the ordinary alongside some sensible formatting to make the structure of the document clear should NOT have a significant impact upon your page's performance...
...and if stripping them out DOES make an impact, you probably are using old/outdated/half-assed coding techniques (hence people still vomiting up tranny or slapping the 5 doctype on tranny) with problems like a code to content ratio in the markup of 10:1 or more. (when 3:1 is a more practical upper limit). Whenever I see someone practicing comment/whitespace stripping it's on pages blowing half a megabyte on delivering 4k of plaintext.
You also have the issue of people using vague/meaningless classnames like "F style2 egbt" -- don't be too smart for yourself; meaningful names on elements "content", "mainMenu", "sideBar" are as much a part of clear legible code as comments. You see nonsense like this:
<!-- start content -->
... and that's serious "whiskey tango foxtrot" territory. If they just named it content, they wouldn't need the comment. It's also part of why classnames like "clear", "left" or "red" are also a miserable failure as they don't answer the question "why" and defeat the point of using CSS in the first place. You should be saying what the element IS, not how it appears. WHY is it red? Is it a standout? Is it something getting emphasis? WHY is it left? Is it a sidebar? a leading plate? If you're going to use classes that way you might as well go back to HTML 3.2 and use the FONT tag and ALIGN attribute as you've COMPLETELY missed the point!!!
But to put that in perspective I consider the 'nav' class/id name completely vague and meaningless; every link on a page is navigation, that doesn't narrow it down a whole lot... Which is why I consider HTML 5's nav element a waste of code, and why I usually give my menu's meaningful names like "topMenu", "mainMenu", "subMenu", "footerMenu", etc, etc, etc...
Bottom line, comments should be used to make vague sections of code clear -- which means you document things that are out of the ordinary (like IE fixes in the CSS) or closing tags that are far enough away from the open to need it... and extraneous bits of ranting just don't belong in there if they do not add any extra meaning to the next person to come along. As many seasoned programmers will tell you if you feel the need to document every single line of code, you need to go back and learn how to program... as in most cases verbose variable names -- or in the case of HTML verbose class/ID names with semantic markup and proper indentation -- can often preclude the need for extra comments.
We aren't talking about compiled languages here where you can comment until blue in the face and it has zero impact on the binary.