From eb02be619634dee7832739c3a3957e46be9b3d92 Mon Sep 17 00:00:00 2001 From: Steffen Becker Date: Thu, 13 Aug 2026 20:14:26 +0200 Subject: [PATCH] fix: a columns section's first block starts flush with the column top MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The rule that drops the space above it never applied to a Word document: :is(p, h1, …, .toc) takes the class specificity of .toc, so the later spacing-model rule tied at (0,4,0) and won on order — and the heading opening a two-column section sat 3.5mm below the column beside it. Zeroing the property both spacing models read settles it, and beats the block's own inline value as a margin would not. Probed: LibreOffice starts both columns level; a two-column page now matches it 45 lines deep, where it diverged at line 8. --- src/styles/editor.css | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/styles/editor.css b/src/styles/editor.css index 852a221..ff2293b 100644 --- a/src/styles/editor.css +++ b/src/styles/editor.css @@ -531,7 +531,11 @@ .paper .tiptap .columns-node { column-fill: balance; } +/* Its first block sits flush with the column top — the space above it is dropped there, + as at a page top (probed: LibreOffice starts both columns level). Zeroing the property + the two spacing models read beats the block's own inline value, which a margin wouldn't. */ .paper .tiptap .columns-node > :first-child { + --space-before: 0 !important; margin-top: 0; padding-top: 0; }