Bug: Exported DOM for rich-formatted nodes is malformed

[kettanaito]

The result of $generateHtmlFromNodes(editor) is a malformed HTML string as it contains unnecessary HTML elements, classes, and style attributes.

Lexical version: 0.38.1

Steps To Reproduce

1. Initiate a Lexical editor with @lexical/rich-text.
2. Create content that looks like this:

3. Export the editor's content to HTML using @lexical/html.

Link to code example:

import { registerRichText } from '@lexical/rich-text'

const editor = createEditor({
  name: 'test'
})

registerRichText(editor)

editor.update(() => {
  const paragraph = $createParagraphNode()
  const one = $createTextNode('One .')
  const two = $createTextNode('Two')
  two.setFormat('italic')
  const three = $createTextNode('. Three.')

  paragraph.append(one, two, three)
  $getSelection()?.insertNodes([paragraph])
})

Then, export the content:

import { $generateHtmlFromNodes } from '@lexical/html'

editor.read(() => {
  const html = $generateHtmlFromNodes(editor)
  console.log(html)
})

The current behavior

<p><span style="white-space: pre-wrap;">One. </span><i><em class="italic" style="white-space: pre-wrap;">Two</em></i><span style="white-space: pre-wrap;">. Three.</span></p>

The following criteria lead me to conclude the resulting HTML string is malformed:

• Redundant <i><em> nesting (the same happens for "bold" format, resulting in the <b><string> nesting).
• Redundant inline styles on HTML elements that already imply those styles from the user agent: <em class="italic">
• Redundant inline style="white-space: pre-wrap;" attributes. Wrapping each span in this inline style results in unnecessarily verbose HTML for larger documents. The same inline style behavior should be applied by the user, if they choose so, on the parent element of the HTML.

The expected behavior

I expect for the resulting html to look like this:

<p><span>One. </span><em >Two</em><span>. Three.</span></p>

This represents the content of the editor with semantic and valid HTML tags.

Impact of fix

• The behavior happens every time, there's no context affecting it.
• Everybody would benefit from this fix since I assume the intention of $generateHtmlFromNodes is to get the valid HTML representation of the editor's contents.

[kettanaito]

Here are the origins of the redundant HTML:

• Inline white-space: pre-wrap;
• Redundant tag nesting:
  • Inner tag (em, strong) gets created here.
  • The entire element is then wrapped in other tags (i, b) here.

I strongly advise the TextNode chooses just one set of tag wrappers based on its formatting. I recommend em, strong, etc as those are more semantically valid then i and b. I have no strong opinion here, whichever tags you prefer are fine by me.

The behavior is evidently intentional, given the comment:

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

Lines 660 to 662 in 12bdc8d

	// This is the only way to properly add support for most clients,
	// even if it's semantically incorrect to have to resort to using
	// <b>, <u>, <s>, <i> elements.

But I don't believe the redundant tag wrapping is.

[etrepum]

The primary use case of DOM export is for the clipboard and the nesting of tags and explicit styles is there to support interoperability with other applications. It’s not designed to produce a serialization for itself to import, JSON is typically used for that.

white-space: pre-wrap is needed in case there are leading, trailing, or contiguous spaces in the text. If it’s not there it won’t be the same string anymore due to the way that the default white-space style normalizes text.

[vadimkantorov]

Maybe a bit related on more finegrained control of HTML import/export/roundtrip works:

• Feature: How can we maintain the html attributes like id, style from backend? #7840

E.g. for a "terse" mode it can be sufficient to include a <style>...</style> element and not duplicate-inline the styles (especially for white-space).

E.g. "terse" HTML export can be useful for SSR/SSG - where document HTML is rendered by lexical as well, but ahead-of-time, and editor is not used on the client-side (e.g. only used in the blog admin zone, not for rendering the posts themselves).

[etrepum]

Rendering for client-side on a property you control is usually best done with the editor, you don’t need export for that. Just render it and save the innerHTML if you want SSR/SSG. There’s a svelte example that demonstrates this technique plus hydration directly from the HTML rather than from a JSON payload.

[vadimkantorov]

@etrepum thank you for the pointer! I'll check it!

For now, I've used sth like the following for SSR/SSG (which relied on $generateHtmlFromNodes):

import { EmojiNode } from "./src/nodes/EmojiNode";

import { TextNode, $getRoot, $selectAll } from "lexical";
import { HeadingNode, QuoteNode } from "@lexical/rich-text";
import { LinkNode } from "@lexical/link";
import { HashtagNode } from "@lexical/hashtag";
import { ListNode, ListItemNode } from "@lexical/list";

import { createHeadlessEditor } from "@lexical/headless";
import { $generateHtmlFromNodes } from "@lexical/html";
import { JSDOM } from 'jsdom';

let input : string = "", html : string = "";
const editor = createHeadlessEditor({
  editable: false,
  nodes: [TextNode, HeadingNode, QuoteNode, LinkNode, HashtagNode, ListNode, ListItemNode, EmojiNode],
  onError: (error) => { throw error;},
});

const dom = new JSDOM();
global.window = dom.window;
global.document = dom.window.document;

process.stdin.on("data", (chunk) => {  input += chunk; });
process.stdin.on("end", async () => 
{
  try
  {
    let editorStateJson = JSON.parse(input);
    if('editorState' in editorStateJson) editorStateJson = editorStateJson.editorState;
    const editorState = editor.parseEditorState(editorStateJson);
    editor.setEditorState(editorState);    
    editor.update(() => { html = $generateHtmlFromNodes(editor, $selectAll()); });
    console.log(html);
  }
  catch (error)
  {
    console.error("Error processing EditorState JSON:", error);
    process.exit(1);
  }
});

---

It would be great to have an official example of generating nice HTML/CSS for SSG...