feat: Better parsing of external HTML attributes & inline styles

[matthewlipski]

This PR adds tests for parsing various HTML attributes & inline styles, and provides fixes so that these tests pass. Namely, these tests include:

• Parsing numbered list start props from start attribute.
• Parsing image width props from width attribute.
• Parsing bold, italic, underline, and strike marks from various tags & inline styles. This includes e.g. b tags and font-weight inline styles for bold marks as well as i tags and font-style inline styles for italic marks.
• Parsing textColor and backgroundColor marks from inline styles.
• Parsing textColor and backgroundColor props from inline styles.
• Parsing textAlignment props from inline styles.

To ensure all tests pass, several changes have also been made to the code:

• Parse rules have been added to textColor, backgroundColor, and textAlignment props for inline styles.
• The textColor and backgroundColor props have been changed, so that they're now applied as attributes to blockContent nodes instead of blockContainer nodes. This is because we would only attempt to parse these props when a blockContainer node is found, i.e. when a div with [data-node-type="blockContainer"] is found. So we would never even attempt to parse these props from external HTML. The CSS has been updated also to account for this change. Also, all other block props are already stored on the blockContent node, so this makes the textColor and backgroundColor props also consistent with that.
• Small fixes have been made to numbered list item and quote blocks.

Additionally, code for color props & marks has been cleaned up slightly.

The large negative diff in this PR is also because a bunch of redundant React unit test snapshots have been removed.

[vercel]

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

Name	Status	Preview	Updated (UTC)
blocknote	❌ Failed (Inspect)		Jul 17, 2025 0:10am
blocknote-website	❌ Failed (Inspect)		Jul 17, 2025 0:10am

[pkg-pr-new]

Open in StackBlitz

@blocknote/ariakit

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/ariakit@1605

@blocknote/code-block

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/code-block@1605

@blocknote/core

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/core@1605

@blocknote/mantine

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/mantine@1605

@blocknote/react

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/react@1605

@blocknote/server-util

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/server-util@1605

@blocknote/shadcn

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/shadcn@1605

@blocknote/xl-docx-exporter

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/xl-docx-exporter@1605

@blocknote/xl-multi-column

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/xl-multi-column@1605

@blocknote/xl-odt-exporter

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/xl-odt-exporter@1605

@blocknote/xl-pdf-exporter

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/xl-pdf-exporter@1605

commit: 0f029ff

[nperez0111]

👍 this looks exactly as I'd have expected it to.

Great work @matthewlipski

[YousefED]

return {}?

[matthewlipski]

Yeah we don't need to parse the color because it's already handled in the parseHTML function of the stringValue attribute.

[YousefED]

can't we omit line 25 / 26 then entirely? it's still a bit confusing right? (maybe tiptap issue)

[matthewlipski]

No, because return {} tells TipTap that the element should get parsed as a textColor mark, and to just use the default attribute values for that mark (here it is equivalent to return { textColor: defaultProps.textColor.default }). The parseHTML function of the stringValue attribute then does its thing, parsing the actual value of stringValue and replacing the default one. Returning false instead means the mark never gets parsed at all.

This is a kind of weird TipTap thing especially with return {}, but it does mostly make sense.

We could choose to parse the actual value of stringValue within the parseHTML function of TextColorMark, but this would result in duplicated code between TextColorMark and TextColorExtension.

[YousefED]

Looks good!

Just realized one caveat; for yjs stored documents the block color data will probably be lost when upgrading (or the document might break entirely, but I doubt that).

Perhaps you can see with Nick if there's a fix for that possible (or a migration path for people upgrading)

[YousefED]

can't we omit line 25 / 26 then entirely? it's still a bit confusing right? (maybe tiptap issue)

[matthewlipski]

Changes from this PR and more were updated and added in #1991, #1998, and #2004