Add highlight TextFormatType

[moy2010]

Add a new highlight variant to TextFormatType, to cover the use case of highlighted text.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
lexical	✅ Ready (Inspect)	Visit Preview	Dec 17, 2022 at 10:27PM (UTC)
lexical-playground	✅ Ready (Inspect)	Visit Preview	Dec 17, 2022 at 10:27PM (UTC)

[trueadm]

I wonder if this might come over confusing because we already have a MarkNode in @lexical/mark that uses <mark>?

[moy2010]

I wonder if this might come over confusing because we already have a MarkNode in @lexical/mark that uses <mark>?

Ah! Didn't know this use case was already covered 🙈 . I'll close the PR then.

[moy2010]

Duplicated functionality

[moy2010]

Re-opening the PR after playing with the MarkNode for a few days, and finding its usage not the best in some use cases.

[fantactuka]

Re-opening the PR after playing with the MarkNode for a few days, and finding its usage not the best in some use cases.

Could you describe cases where existing marks are not fitting?

[moy2010]

Could you describe cases where existing marks are not fitting?

Yes, of course. The simplest one is where the user wants to re-adjust the range selection. Let's take a simple text with two words:

first second

And the user wants to highlight only first, but for accuracy reasons while selecting the text with the mouse, the user selects too much and highlights: first s. Then the user wants to unhighlight the unnecessary part ( s), selects it and hits the button to do so, but because this is being wrapped by an element node, everything will be "unhighlighted".

I know it's a silly example, but it reflects that the UX of selecting/highlighting text with an element node rather than a text node format is cumbersome.

[trueadm]

After thinking about this more. It makes sense for your use case. MarkNode elements do have slightly different heuristics that are more about structure than styling/formatting. Thanks for the PR.