The editor's view right now has a few inconsistencies with how it is visible in the publication view. We need to make both matches as close as possible. this comes with a lot of challenges that with the hm://z6MkuBbsB1HbSNXLvJCRCrPhimY6g7tzhr4qvcYKPuSZzhno/projects/project-introducing-list-node-type project and some other cleanups the Frontend team has done to the editor can make this more possible.
Problem
The hm://z6MkuBbsB1HbSNXLvJCRCrPhimY6g7tzhr4qvcYKPuSZzhno/projects/new-publish-mental-model?v=bafy2bzaceb274cnkrc2o52fdcf7jdlcd7o3yhkagjjjnbbmeef4gbu2w5pcuc&l project intends to make the editor always be rendered, even in published content. This requires the editor view to look identical to the published view. Furthermore, right now the published view looks noticeably better than the editor view, so rendering the editor would be a visible downgrade.
Where the differences come from
The editor (packages/editor) and the published renderer (packages/ui/blocks-content.tsx) are two completely separate rendering pipelines:
Spacing system
Editor uses fixed absolute values (padding: 12px 0 3px 0).
Published uses CSS-variable-driven spacing (calc(var(--layout-unit) / 3)).
Heading sizes
Editor has hardcoded per-level sizes (`30px`, `24px`, `20px`, `18px`, `16px`).
Published derives sizes from SeedHeading component with responsive scaling. Published headings adapt better across viewports.
Media blocks
Editor wraps media in MediaContainer with no specific padding/margin strategy.
Published uses negative margins to extend full-width with padding offset, max-height: 600px, object-fit: contain.
Code blocks - container styling differs
Published uses negative-margin full-width treatment with rounded borders.
Lists
Editor uses marker progression (disc, circle, square) with padding-inline-start: 1em.
Published uses list-style-position: outside, display: list-item !important, with different padding resets.
Alignment and marker positioning differ.
Grid layout
Editor has grid-specific overrides in Block.module.css.
Published uses Tailwind responsive grid classes (`grid-cols-1`, `sm:grid-cols-2`, `md:grid-cols-3`).
Different max-heights and containment for media in grids.
Solution
Systematically align the editor's visual output with the published view, block type by block type. The rendered DOM elements may differ (ProseMirror nodes vs plain React).
Steps
Port the published view's --text-unit and --layout-unit custom properties into the editor's root container. Refactor Block.module.css to derive spacing from these variables instead of hardcoded pixel values. This is the single highest-impact change as it brings all block spacing into alignment.
Work through each block and list type and match the editor's styling to the published view
Side-by-side comparison of the same document rendered in both views to verify alignment:
A document containing all block types
Deeply nested content
Grid layouts with mixed media
Long-form text with headings at all levels
Edge cases: empty blocks, wide images, long code blocks, complex math
Scope
1-2 weeks. It is meticulous work that requires changing and testing all block types
cc. hm://z6Mkvz9TgGtv9zsGsdrksfNk1ajbFancgHREJEz3Y2HsAVdk?v=bafy2bzaceaf5y2554kmdly7yz55fowqum4546bpa2gmi5gntflhlf4gaomdg6&l hm://z6MkrbYsRzKb1VABdvhsDSAk6JK8fAszKsyHhcaZigYeWCou?v=bafy2bzacecoevvu2ebpntbrhm552uqp3ag5vrxvukpk7a4vvfmhazkk7smu5y&l hm://z6MkgisVMELvqnsCo3dYmtVpy8PiqPGMVwfAyBWFn84vebq4?v=bafy2bzaceciguevcgg7lacbo7fgix52zw3ewydimhmvbgyfzepmliapuaepam&l
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime