Selecting an atom used to clear every native range and leave the editable
root focused with NO selection. The browser then invents a caret at the
START of the content, `selectionchange` reads it, and the model's node
selection is overwritten by a text caret in the first block — so the
Enter meant to exit the freshly inserted atom split the opening
paragraph, and typing replaced its text. Reproduced live within a minute
of using the slash menu.
- the bridge now writes a node selection as `range.selectNode(blockEl)`;
the read path maps that range to null, so selectionchange keeps its
hands off the model
- beforeinput guards the node-selection state: browser edits through the
element-wrapping range are prevented; delete falls through to
deleteSelection, insertParagraph to exitAtom
- browser regression test walks the exact race: select atom → DOM range
exists → selectionchange rewrites nothing → Enter lands a paragraph
below the atom
writekit 0.0.4.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two gaps an author hits within the first minute of using atom blocks:
- there was no way to add a paragraph after a non-text block. Enter on a
selected atom now starts a paragraph below it (exitAtom, chained before
splitBlock), and a click on the root's padding below a trailing atom
does the same — ends-in-text just places the caret at the end
- the slash menu ignored its own overflow: keyboard navigation walked the
highlight out of view (now scrollIntoView nearest), and a background
wheel scroll tore the menu off its caret anchor (now prevented outside
the menu; scrolling the list itself stays native)
- BlockMeta gains `description`; the menu shows a detail pane beside the
list with the highlighted item's description, replaceable wholesale via
the new #preview slot. Headless stays headless: the pane is unstyled
text and appears only when there is a description or a slot. Preset
blocks are all described
Both floating menus (slash, bubble) are re-layered to the combobox
convention: PopperRoot provides the positioning context OUTSIDE a bare
Portal, which resolves its target from the ConfigProvider's
teleportTarget — the previous hardcoded to="body" was overriding the
app's configured target. A Combobox itself is the wrong base here on
purpose: its keyboard lives on ComboboxInput, while a suggestion menu
must leave focus in the contenteditable — the editor is the input.
writekit 0.0.3.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
robonen