Nested comment tags.

[RokeJulianLockhart]

What problem are you trying to solve?

<!-- -->

tags cannot be nested like

<!--
	<!-- -->
-->

meaning that using comments to temporarily remove well-described code in order to debug it is immensely difficult in HTML.

What solutions exist today?

Some IDE extensions automatically break the tags in non-standardized manners, like https://github.com/philsinatra/NestedCommentsVSCode/blob/9c25135847af99c89e66b14e7396a3bf2b0d7cf0/README.md#html-syntax.

However, I could also use a custom tag. This may appear as if it is the immediately easier solution to this, but significant disadvantages to immediately choosing this option exist:

Choosing to add a new (for instance, <comment>) tag means that not solely must I propose and successfully implement a new element, I must additionally deprecate the previous absurdly widely-used <!-- --> element. This seems to me as if it would cause more disruption, because we couldn't leave both in, lest they duplicate functionality.

Considering that modiying the parsing of the existent comment tag wouldn't affect HTML users - developers - in any manner I can forsee, modifying the engines to allow the comment tag to be nested sounds like a better idea.

I would like to eventually propose a <comment> tag. However, I believe that this should come after this work has been accomplished.

How would you solve it?

I would permit the tags to be nested. I would like this support to be unanimous to avoid situations like https://stackoverflow.com/a/6698115/9731176.

Anything else?

1. For those unaware of why this isn't already possible, https://stackoverflow.com/revisions/12102131/6 explains it well.
2. I've posted this to https://new.reddit.com/user/rokejulianlockhart/duplicates/1b69fcv/support_fixing_html5s_inability_to_nest_comment/?utm_source=share&utm_medium=web2x&context=3 so that it might become more visible.

[annevk]

We cannot make a breaking change like this to how HTML is parsed. Especially with so little justification. I hope you understand.

[annevk]

https://whatwg.org/working-mode#changes describes the process, but in this specific case I know that it's extremely unlikely you'll get implementer support as making a breaking change to how HTML is parsed is not done lightly.

I can tell you that WebKit would not want this change to be made, but maybe you can convince other implementers. I'll reopen for now given that you don't seem convinced.

[RokeJulianLockhart]

#10153 (comment)

Thank you, @annevk. I'm aware that this shall be an uphill battle, considering how much time this issue has been left unfixed.

[RokeJulianLockhart]

#10153 (comment)

@annevk, I know solely that Google, Mozilla, and Apple are stakeholders in this, so do you know of any implementers I might have missed? Additionally, how do you suggest I contact them? I've always created issues in their respective public bug trackers - is that the standard way to propose things like this?

[kbrosnan]

I can see your enthusiasm for this feature. This change would be a breaking change to how HTML is parsed. This would break correctly parsed pages that currently exist. It would add a significant layer of complexity when parsing HTML.

This change would need an exceptional use case to be considered. Easier debugging is not exceptional. Some complied languages support this feature, again not exceptional.

Filing bugs, Anne already said that WebKit would not accept such a change. For Mozilla it would get duplicated to an old invalid bug like 195133. I expect a similar response from Blink/Chrome developers.

I suspect that this feels circular but you are proposing a fundamental change that affects any page that uses comments. Such a change is not taken lightly.

[RokeJulianLockhart]

#10153 (comment)

@kbrosnan, thanks. Indeed, I recognise what you've stated.

Nevertheless, my aforestated rationale for desiring this change is that I cannot see a world in which implementing a replacement comment tag (the sole alternative I've envisioned) is an easier breaking change to implement. Additionally, I constantly need the ability to nest comment tags, so I do need a solution. The work necessary to attempt to convince stakeholders would not be worth the effort were this not significantly problematic for me.

Regardless, I realize that others may prioritize stability. I vehemently disagree with this personally, but recognize that mere opinion shall not change that, so I shall not unnecessarily invoke ire by fighting with stakeholers. I only intend to explain as best I can the advantages of reconsidering this limitation, and leaving it for them to decide.

WebKit I consider a somewhat special case in that they tend to be somewhat unnecessarily conservative, and consequently, I would like to consider their opinion separately to the others'. Regarding Mozilla, specifically their aforementioned bug tracker's extensive history which appears to cover every proposal known to humankind, I believe triage identifying potentially duplicate closed issues shan't be a problem. That's because Mozilla has used multiple different triage practices during the past, some of which they recognise unnecessarily locked bugs. Additionally, they tend to reconsider duplicates if they provide new information and the reporter is receptive to feedback.

[zcorpan]

We will not implement this for Gecko.

As already mentioned, this would break existing pages that have this syntax and expect the current behavior. This alone is a sufficient blocker.

But I think there's also another aspect here. When changing how HTML parsing works, we need to be consider if it introduces a new XSS problem. I believe this would: let's say a website allows untrusted input but uses an HTML-parser based sanitizer to remove anything that can run scripts. Comments are considered safe. If the website's backend implements this change, but the user's browser does not (it takes a long time for all users to update even if all browsers were to ship a coordinated change), then the user is now vulnerable to XSS.

What you could do instead is to use the template element, which can be nested and makes stuff inside it inert.

For those unaware of why this isn't already possible, https://stackoverflow.com/a/12102131/9731176 explains it well.

The SGML-style comment parsing issue was solved in the spec in 2006, so that is not relevant.