Nested comment tags. about html HOT 8 CLOSED

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

from html.

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.

from html.

#10153 (comment)

@annevk, what is the procedure for this, then? If I've supposedly no jurisdiction, yet the desire to implement a positive modification, I would like to be provided the opportunity to try to do so correctly.

from html.

#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.

from html.

#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?

from html.

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.

from html.

#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.

from html.

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.

from html.