fix: Selection clicking between blocks

[matthewlipski]

Problem

Currently, .bn-block-content elements have 3px of padding above and below them. When clicking this padding below a block, the selection is moved to the end of that block. Likewise, clicking the padding above moves the selection to the start. Because the padding we use only results in 6px of extra space between blocks though, this behaviour makes it seem like the cursor is randomly jumping to the start/end of a block.

Solution

This PR fixes this UX issue by changing changing the way in which the extra vertical space is added to blocks with content. Instead of using CSS padding, the line-height is increased. This makes it so the selection instead moves to the position closest to the cursor.

Before:

Screen.Recording.2025-05-23.at.21.20.42.mov

After:

Screen.Recording.2025-05-23.at.21.24.42.mov

Caveats

The only side-effect of this is that when the selection is expanded, the blue background is slightly taller (the Playwright snapshot updates show this change).

There are also some slight differences between browsers for how the selection is set:

• Chrome seems to have 1 row of pixels on the border of 2 blocks, where if you click this line, the selection gets moved to the start of the 2nd block.

Screen.Recording.2025-05-23.at.21.30.04.mov

• Safari in general handles selection setting a bit differently with increased line height. Clicking near the bottom of the block will move the selection to the end of the block as if it were padding.

Screen.Recording.2025-05-23.at.21.33.06.mov

Alternatives tried

Using padding-bottom instead of padding-block: Caused misalignment with the nested block left borders and background color props. Tried to hack around this by adding padding-top to .bn-block-content:first-child & reducing padding-bottom on .bn-block-content:last-child. However, this caused the side menu to be misaligned, as it expects block content of a given type to always have the same height.

Using margin instead of padding: Didn't change the behaviour.

Custom selection handling logic: Was overly complex and somewhat hacky.

[vercel]

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

Name	Status	Preview	Updated (UTC)
blocknote	✅ Ready (Inspect)	Visit Preview	May 23, 2025 7:03pm
blocknote-website	✅ Ready (Inspect)	Visit Preview	May 23, 2025 7:03pm

[pkg-pr-new]

Open in StackBlitz

@blocknote/ariakit

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

@blocknote/code-block

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

@blocknote/core

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

@blocknote/mantine

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

@blocknote/react

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

@blocknote/server-util

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

@blocknote/shadcn

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

@blocknote/xl-ai

npm i https://pkg.pr.new/TypeCellOS/BlockNote/@blocknote/xl-ai@1716

@blocknote/xl-docx-exporter

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

@blocknote/xl-multi-column

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

@blocknote/xl-odt-exporter

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

@blocknote/xl-pdf-exporter

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

commit: cc836b9

[nperez0111]

👍 this looks about right to me. Good work on this, I know it can be annoying

[YousefED]

Thanks for exploring this

• on https://blocknote-git-click-between-blocks-fix-typecell.vercel.app/basic/default-blocks the list bullets / checkboxes currently have a weird offset
• a downside of this solution is that now there's no way to visually distinguish between 2 blocks vs 1 block with a hard-break (shift+enter). I don't think there's a good way to solve this (ideas @nperez0111?).

Given the last point, maybe we should hold off on this for now

[nperez0111]

Oof good catch @YousefED, yea given that the line-height is the majority of this fix, it looks like we might be at a stalemate here.