Feature: Custom `textFormatMode` to choose how text formatting is applied

[kettanaito]

Description

I propose Lexical gave the user a choice in how they want the inline TextNode formatting to be applied.

Currently, inline formatting is applied via inline styles taken from editorConfig.theme[formatType]. This leads to HTML elements that look like this:

<strong class="font-bold italic" data-lexical-text="true">Content</strong>

Instead, I would like for the outputted HTML to resemble the final, valid HTML as close as possible:

<strong data-lexical-text="true"><em>Content</em></strong>

Considerations:

• The parent element remains TextNode. Formatting (tag nesting) is applied to the inner children of that element whenever applied.
• Make this behavior config-dependent:

createEditor({
  textFormatMode: 'inline' // default `'theme'` for backward compatibility
})

Impact

• No impact on existing users since the behavior in question is opt-in and backward -compatible.
• Improved HTML output and smaller gap between the runtime and the output editor states.

Maintainer impact

This becomes dependent on config.textFormatMode:

lexical/packages/lexical/src/nodes/LexicalTextNode.ts

Line 273 in 12bdc8d

setTextThemeClassNames(innerTag, 0, format, innerDOM, textClassNames);

Preserve getElementInnerTag as-is:

lexical/packages/lexical/src/nodes/LexicalTextNode.ts

Lines 125 to 133 in 12bdc8d

	function getElementInnerTag(node: TextNode, format: number): string {
	if (format & IS_BOLD) {
	return 'strong';
	}
	if (format & IS_ITALIC) {
	return 'em';
	}
	return 'span';
	}

Presently, it short-circuits due to early return for every format so you cannot get <strong><em> nesting in case text format has both IS_BOLD and IS_ITALIC.

This function will be used conditionally based on config.textFormatMode. If the mode is set to 'inline', instead the created dom for TextNode will be recursively wrapped in the HTML elements representing all the text formatting applied to the node.

Affected logic is here:

lexical/packages/lexical/src/nodes/LexicalTextNode.ts

Lines 489 to 490 in 12bdc8d

	const outerTag = getElementOuterTag(this, format);
	const innerTag = getElementInnerTag(this, format);

And here:

lexical/packages/lexical/src/nodes/LexicalTextNode.ts

Lines 514 to 517 in 12bdc8d

	const prevOuterTag = getElementOuterTag(this, prevFormat);
	const nextOuterTag = getElementOuterTag(this, nextFormat);
	const prevInnerTag = getElementInnerTag(this, prevFormat);
	const nextInnerTag = getElementInnerTag(this, nextFormat);

I don't mind the order of nesting to be fixed so TextNode can reliably produce outerTag but have nested innerTags.

[etrepum]

If you want HTML that’s the same as what you’ve rendered in the editor you can get its innerHTML or just directly render with a headless editor. The export functionality looks weird because it’s designed so that copying from lexical and pasting into other applications works as well as possible by default for the built-in nodes.

There is some ongoing work to provide more flexible and contextual overrides for import and export of DOM using extensions in #7885

[kettanaito]

@etrepum, thanks for a quick response.

you can get its innerHTML or just directly render with a headless editor

Wouldn't both of these approaches suffer from the behavior reported in the issue? The malformed HTML is in the DOM, which means .innerHTML will include redundant tags as well.

Is using the headless editor somehow affects the HTML output from TextNode? I haven't found any such checks in the node's class implementation to suggest it won't produce redundant wrapping.

[etrepum]

The rendered editor doesn’t use the same DOM as the export HTML because its only concern is displaying the content and mapping the DOM to the lexical document correctly. It does not need to add or remove anything for interoperability with other applications.

My suggestion is to use a headless editor to render the editor into an off-screen HTML element, NOT to call export.