A paper colour per block, and blocks that fit their text

Featurekamo-internal
Shipped
September 3, 2026 at 3:43 AM UTC
Author
Kamo
Commit
bf70ce4

BLOCKS NOW FIT THEIR CONTENT. The reader's blocks were all 200px tall whatever they held, because richTextExtension configures the editor with minHeight: 200px — the article composer's shape, where the editor IS the page. Switching the reader to RichTextView removed it; nothing in the pane clamps a block's height now, so it is exactly as tall as its words. THE COMPOSER'S EDITORS GROW INSTEAD OF SCROLLING. Same 200px, plus overflow: auto on the container, meant every block opened three lines too tall and then handed itself a scrollbar rather than growing — a scrollbar inside a block inside the page's scroller. KbArticleEditor gains `autoGrow`: the container stops scrolling, the writing area starts at one line's height, and the root sizes to content instead of filling its host. Opt-in, so the article composer keeps the shape that is right for a page-sized document. PAPER COLOUR. Each block carries one, picked from NoteColorMenu — the same menu and the same palette the notes and the launchpad's panes use, so a swatch means one thing across the product rather than three. The colour is stored as the palette ID and resolved through resolveStickyColor at render, so both the composer and the Interaction Center paint from one source and a later palette correction reaches scripts written today. In the reader a coloured block keeps its colour whether or not it is the current one. "Where am I" is already carried by the border, the lift and the spine; dimming the paper as well would make the author's choice look like a rendering fault.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing