Any HTML will be escaped by React (try using formatting or adding a link to the caption).

Is there another approach?

TIL about .toHTMLString() 🙂 . The only issue is that if the caption text in the pattern is anything other than plain text, the HTML tags will show up in the caption in the editor:

Could we pass it to dangerouslySetHTML and escape it like:

diff --git a/packages/block-library/src/image/image.js b/packages/block-library/src/image/image.js
index 4b46d085a77..3405c21007d 100644
--- a/packages/block-library/src/image/image.js
+++ b/packages/block-library/src/image/image.js
@@ -35,6 +35,7 @@ import { switchToBlockType } from '@wordpress/blocks';
 import { crop, overlayText, upload } from '@wordpress/icons';
 import { store as noticesStore } from '@wordpress/notices';
 import { store as coreStore } from '@wordpress/core-data';
+import { safeHTML } from '@wordpress/dom';
 
 /**
  * Internal dependencies
@@ -795,7 +796,11 @@ export default function Image( {
 			{ img }
 
 			{ lockCaption && (
-				<figcaption>{ attributes.caption?.toHTMLString() }</figcaption>
+				<figcaption
+					dangerouslySetInnerHTML={ {
+						__html: safeHTML( attributes.caption?.toHTMLString() ),
+					} }
+				></figcaption>
 			) }
 
 			{ ! lockCaption && (

I see that there's precedent for this in https://github.com/WordPress/gutenberg/pull/33814/files

ah, yeh, html escaping 🤦. Instead of using dangerouslySetInnerHTML we could pass through props to the RichText component to disable editing. We can do this either with an explicit disableEditing and use that to set the same shouldDisableEditing flag that block bindings lockAttributesEditing is using - as here.

Or we could pass contentEditable and aria-readonly props from the image caption and plumb these through the Caption component with a ...props, as here .

The second one does not alter the external API of the RichText component so maybe that is the approach to take? Happy to hear others thoughts on this.

Or we could pass contentEditable and aria-readonly props from the image caption and plumb these through the Caption component with a ...props

It might be risky, as I think there's some programmatic modification of the contenteditable attribute directly via the DOM API elsewhere in the codebase (for example - https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/components/writing-flow/use-arrow-nav.js#L265).

So you could set it via React, but it might not stay that way.

We can do this either with an explicit disableEditing and use that to set the same shouldDisableEditing flag that block bindings lockAttributesEditing is using

This could be a good idea, though it may need to be private initially, which means going through the dance of making a private version of the RichText component.

yeh, I don't like relying on ...props drilling for something critical as it can easily get broken somewhere in the component chain, as well as by the external DOM manipulations, so will follow up on the disableEditing approach even though it is trickier in terms of altering the API.

I suspect I have taken the private API docs too literally here - they show an example with the new prop prefixed with private, but I suspect that negates a bit of the value of the private API, in that once the API is made public we can just unwrap it and all the existing props will just work without having to be renamed?

have removed the prefix

This doesn't seem scalable. What about rich text everywhere else?

@ellatrix I don't see it as something that needs to be scalable. At the moment caption is disabled because it's an edge case, one of the few content attributes that block bindings can't process (due to the lack of a replace_inner_html function in the html processor).

In the future when caption is supported by block bindings it'll be possible to revert this PR.

Oh, ok