Hosted onseed.hyper.mediavia theHypermedia Protocol

    assignee:#Yskak

    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 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 New Publish mental model 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

    Do you like what you are reading?. Subscribe to receive updates.

    Unsubscribe anytime