Part of #53874

A number of block supports currently rely on server side rendering to generate frontend styles. This means that our serialization function (serialize) doesn't produce HTML that is ready to be rendered while including all styles. While in WordPress this can be beneficial so that block supports are dynamically generated at render-time via PHP, for 3rd party editors, a solution should be provided where these styles can be automatically injected at render-time via JS, to produce final render-ready HTML.

The task

Provide a way to generate the final HTML including styles (some kind of render function) that can be used by third-party JS editors. This code already exists and is being used to generate these styles in the editor. A solution could be introduced to allow the generated styles to be output in the editor, but to also be (optionally) output during serialization / render.

The generated styles for block supports includes (but is not limited to) inline styles within block markup, svg markup to be appended to the end of the HTML markup, and style tags / CSS intended to be output alongside the markup.

Block supports that depend on server-rendering include

• Duotone
• Elements styles
• Layout
• Position

For example, currently the Layout block support uses a portal to output generated layout styles in JS, running on a filter over editor.BlockListBlock:

What if there was a parent function of some kind that performed similar logic, but that could output both in this filter for the editor, as well as when blocks are saved or rendered in JS for a 3rd party editor's frontend output. That output could either be dynamically generated in JS, or that JS could generate the HTML, and a 3rd party could store it in their own database somewhere, depending on the 3rd party's requirements.

Task breakdown

TBC, but some questions include:

• What might the API for this look like?
• How to ensure each block support's unique needs are covered by it.
• Can a 3rd party easily switch the behaviour on-or-off to cover 3rd parties that do want to include styles, and those that do not (e.g. output that just wants semantic, unstyled markup for newsletters or feeds)