# Gutenberg Is Huge for a Reason > [!question] Lingering Questions > - Can WordPress expose a more explicit cross-editor preservation contract without requiring every alternative client to embed the Gutenberg runtime? > - Does generic text/image editing inside a preserved "island" ever mutate markup that later fails Gutenberg's own validation? > - How much of continued Classic Editor usage is genuine writing-workflow preference versus legacy dependency or inertia? (The article treats install counts as a vote; that's an unverified inference.) > [!tip] Article Ideas > - A four-level compatibility vocabulary for WordPress editors — display / preserve / constrained-edit / full-edit — as a reusable framework beyond this one project. #articleseed > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Preservation Compatibility Differs From Editing Parity]] — this note's own permanent candidate > - [[3. Resources/Permanent Notes/A Never-Build List Protects Product Identity]] — this note's own permanent candidate > [!info] Vocabulary > - **Atomic island** — a block of preserved, complex markup that a smaller editor treats as one bounded, non-editable (or narrowly editable) object rather than regenerating it. > - **Client-owned serialization** — stored block markup that exists only because a plugin's JavaScript save routine generated it; the server-side registration alone can't reproduce it. ## Metadata - Source: [Gutenberg Is Huge for a Reason. That Does Not Mean Every Editor Has to Be.](3.%20Resources/Readwise/Articles/Gutenberg%20Is%20Huge%20for%20a%20Reason.%20That%20Does%20Not%20Mean%20Every%20Editor%20Has%20to%20Be..md) - Category: Articles ## Author's thesis (Adler Q1+Q2) Gutenberg and Minn Admin (the author's smaller writing-focused editor) are not larger and smaller versions of the same product — they serve different jobs. Gutenberg's size follows from real platform responsibilities: block registration across many CMS surfaces, third-party block applications, nested layout, and Full Site Editing. Minn can stay small by declining those responsibilities, editing only common prose, and preserving everything it doesn't own as an untouched "island," handing design work back to Gutenberg through a one-click escape hatch. ## Key arguments (≤3) 1. Client-owned block serialization means a smaller editor can't safely regenerate every third-party block's saved HTML from server-visible data alone — the plugin's own save routine is the only reliable source. 2. An island/preservation fallback can deliver real compatibility (nothing is corrupted or lost) without claiming full editability — "supports Gutenberg blocks" collapses several very different levels of support into one phrase. 3. A focused editor needs a firm, maintained "never-build" list, or it inevitably re-absorbs the architecture of the platform it set out to be smaller than. ## Claim atoms ### Focused editors preserve what they don't own > [!quote] ID:source-p20 > A simple block carrying an attribute the serializer cannot reproduce from the DOM becomes an island instead of a silent data loss. Located in the description of Minn's allowlist-and-fallback behavior. Matters because safe refusal — not clever regeneration — is the mechanism that lets a smaller editor coexist with markup it doesn't fully understand. **Tags**: #xref #articleseed ### Product scope explains editor size, not incompetence on either side > [!quote] ID:source-p03 > They are different products that happen to be both called an editor. Located near the article's opening resolution of the size comparison. This is the piece's thesis: bundle size and feature count only become legible once each product's actual responsibilities are named. **Tags**: #xref ### Reimplementation creates a permanent parity treadmill > [!quote] ID:source-p35 > Every control you reimplement becomes a permanent parity treadmill against the vendor's next release. Located after the Stackable design-library example. Matters because the cost that determines whether a focused tool stays focused is ongoing maintenance, not one-time development effort. **Tags**: #articleseed #aphorisms ## Permanent candidates - **Preservation compatibility differs from editing parity** (from H1) — a general claim about what "compatible" can mean when full behavioral equivalence isn't achievable. Promoted below. - **A never-build list protects product identity** (from H3) — generalizes past this one editor to any focused tool sitting next to a larger platform. Promoted below. ## Processing checklist - [x] Three Literature atoms have claim headers, exact quotes, context. - [x] Two Permanent candidates promoted. - [x] Quotes checked against the captured article body. - [ ] Reader-native highlight IDs unavailable — source supplied no highlight records, local paragraph identifiers used instead. ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — the article is fundamentally an argument about compatibility contracts and scope boundaries between a platform and an alternative client built on its data format