search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.32k stars 4.12k forks source link

Inline HTML comments are removed when a Block is edited #13318

Open danielbachhuber opened 5 years ago

danielbachhuber commented 5 years ago

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:

htmlcommentdisappear

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):

danielbachhuber commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 1 year ago

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 commented 1 year ago

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.