text-editor: HTML styling is stripped away when editor is prepopulated

[FredrikWallstrom]

Current behavior

When you prepopulate the editor with some HTML, for example an email, some styling is stripped away. Unfortunately, I haven't been able to locate exactly where this happen because I'm not that familiar with the prosemirror-adapter.

EDIT: It actually looks like prosemirror is rewriting the entire HTML. Tags are replaced, for example div tags is replaced with p tags, b tags is replaces with strong tags. In most cases, this might be OK, but in other cases it might have fatal consequences, for example with table tags, as they are completely removed and the table content is replaced with p tags.

If I remove the change handler for the value, my HTML is kept with full styling when it is display in the markdown component in the feed. If I have the change handler in place, and I change something in the editor, the HTML styling is lost. This is a sign for me that the HTML is manipulated in the prosemirror-adapter somewhere.

Steps to reproduce the behavior:

        this.body = "<div style='color: red'>RED COLOR</div>"

        return [
            <limel-text-editor
                onChange={this.handleBodyChange}
                value={this.body}
                contentType={'html'}
            />,
            <limel-markdown value={this.body}/>,
        ];

Produces the following:

Readonly editor mode:

Not readonly mode produces the following:

Change handler removed, HTML styling is kept in the feed:

The value has changed, HTML styling is not kept in the feed:

Expected behavior

Styling should not be stripped away from the HTML.

Environment

• lime-elements version:
• Framework used:
• Logs:

[adrianschmidt]

I thought I'd throw in a link to the Slack thread about this bug here: https://lime-technologies.slack.com/archives/C1K6TN9BK/p1728391028828459

I haven't read it yet, so I don't know if there's anything in there that isn't in the issue description, but I wanted the reference to the thread on this issue, just in case 🙂

[john-traas]

This is definitely possible to solve. We've put together the text-editor with a add it when it's needed approach.
I think the main considerations are on how we want to solve it. I think part of the issue will be solved when we solve mentions.

It could be a bit of a rabbit hole and I haven't really gone in-depth to what it might entail.

It could be as pedantic as simply adding a nodeSpec for each type of default HTML tag that we want to support. It might be more complex than that. For mentions we're creating an interface that allows us to specify a tag name (in this case a custom component) and the allowed attributes for that tag. These will most likely be passed as properties to the text editor.

In the text editor we'll have a small factory to create the nodeSpec so the prosemirror adapter can serialize and parse it.
For anyone interested here's the first implementation which is under review: #3139

It might be a bit heavy to expect each consumer to tell the text-editor which HTML tags it want's the editor to recognise. So as far as HTML processing it might be a better option to go with a list of default HTML tags which we pass to the node spec factory on start up.

[eketorp]

Maybe an update on this one now that mentions are live since some time ago?

[john-traas]

There's a bit of a backlog related to parsing/serialization of content. Namely:
Tracking pixel causes "save changes" to pop up immediately when opening the feed

Custom link paste plugin not respecting line breaks

Issue on preserving linebreaks

Preserving whitespace when toggling block types

[john-traas]

I plan on working my way through the above issues during this cooldown.