Inline HTML comments are removed when a Block is edited

[danielbachhuber]

Describe the bug

If a Block has an inline HTML comment, the HTML comment is stripped out when the Block is modified.

Sample text:

This is my paragraph text with <!-- html-comment -->an HTML comment<!-- /html-comment -->

To Reproduce
Steps to reproduce the behavior:

1. Create a new Paragraph Block.
2. Add the sample text in HTML mode.
3. Switch to Visual mode.
4. Switch back to HTML mode and see that the HTML comment persists.
5. Switch to Visual mode and make some edit to the text.
6. Switch back to HTML mode and see that the HTML comment has disappeared.

See GIF:

Expected behavior

My expected behavior is that the HTML comment persists when I edit the text.

In the scenario where I edit within the boundary of the HTML comment, my expected behavior is that the Block Editor would mirror the Classic Editor.

Desktop (please complete the following information):

• OS: Mac OS 10.14.2
• Browser: Firefox 64.0.2
• Version: Gutenberg 4.8.0

[danielbachhuber]

Flagging Needs Technical Feedback because I'm not sure what the expected behavior is there. It's also probably lower priority in the grand scheme of things.

[ellatrix]

I'm not sure either. What's a good use case for allowing comments? If we allow the random comments, I think they should somehow be visualised in the visual editor.

[danielbachhuber]

What's a good use case for allowing comments?

I don't have a good use case, per se. We're currently using HTML commands to mark specific text as "ignored":

Some specific <!-- tasty-links-ignore -->text to ignore<!-- /tasty-links-ignore --> in-between the HTML comments.

I've also seen HTML comments used to store data within the post content.

If we allow the random comments, I think they should somehow be visualised in the visual editor.

Can you explain this thinking further? This would be a departure from the Classic Editor.

[ellatrix]

It sounds like use cases that should be covered by rich text APIs in the future. You want to apply some meta info to some text. Or you want to store an object with data.

Can you explain this thinking further? This would be a departure from the Classic Editor.

In the visual editor the comments would be invisible, so the user would be able to delete the comments without knowing.

[danielbachhuber]

It sounds like use cases that should be covered by rich text APIs in the future. You want to apply some meta info to some text. Or you want to store an object with data.

Cool. That could work although, importantly, we'd want to enrich the content server-side and then pass it to the client (not replicate our existing server-side logic in the client).

In the visual editor the comments would be invisible, so the user would be able to delete the comments without knowing.

Isn't this the case in TinyMCE though? I think it's a reasonable expectation, given the semantic nature of HTML comments.

[RolfKyburz]

I fully agree with @danielbachhuber on the HTML comments: these comments have been a genuine feature of HTML since the early days, and the block editor now deleting them arbitrarily / at will is utterly bad practice: you must not change the rules "just like that"! Yes, comments are invisible in the visual editor — as they are in the rendered page: that is the way they are meant to work. OK, making them visible (maybe optionally?) in the editor would be nice-to-have, but is not a prerequisite. I have a rather complex WP site with >500 posts and 1.5 million words — the only way I could make searching work robustly and efficiently was to hide specific search terms in HTML comments. If such comments are arbitrarily deleted, this not only defeats my search engine, but even just restoring such comments & search terms (and finding out that they are missing in first place!) is a real pain in the backside. Sure, I could put the search terms at the end of my posts, in a tiny and/or transparent font — but that is not only very clumsy, but again an enormous amount of work to retrofit to 500+ blog posts. the same would be true for putting them in a meta tag — plus, I don't know whether I could use local WP searches (in the WP posts listing, or in the user front end search tool) to look into meta tags.

[strarsis]

Or as a middle ground, add a code-comment block that only shows up in the editor, and is stripped during rendering, or with an attribute that toggles that (frontend visible or not)?

[RolfKyburz]

I have now resorted to an HTML block consisting of inline HTML comment only. To me, this works for the purpose of embedding hidden search text in a blog post. That doesn't help, though, in hiding text within a paragraph. I often would like to do that in "live documents", i.e., blog posts that evolve over time, and where I'd like to embed text that I want to activate at a later stage, or which is still missing some information before it can be revealed, just as @danielbachhuber explained above.