# Editable Blocks Inside the Custom HTML Block > [!question] Lingering Questions > - How does invalid-markup recovery work when the shell is locked and a user's edit produces something the block validator rejects? > - What capabilities/sanitization apply specifically to AI-generated shells — the dev note calls constrained editing "immediately safe to edit" but that's a structural claim, not a security or accuracy one. > - Can users reliably tell the difference between the editable slot and the fixed shell, or does the lock state need a stronger visual affordance than currently described? > [!tip] Article Ideas > - The "safe to edit" equivocation flagged in the deep-read's Logical Validity section is worth its own short note: structural safety (can't break the shell) is not the same claim as security safety (can't be exploited) or accuracy safety (content is correct) — a reusable distinction for evaluating any "safe by design" AI-tooling claim. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Editable Slots Separate Content Rights From Structural Rights]] — the Permanent note already extracted from this exact source > - [[3. Resources/Permanent Notes/Bounded Action Spaces Not Better Models Make Agents Safe to Run]] — same "constrain what can change, not just what tool is available" logic > - [[3. Resources/MOCs/Product & Startup Instincts MOC]] > [!quote] Vocabulary > - *innerContent* — a `core/html` block-variation property that maps static HTML fragments around `innerBlocks` slots, with `null` placeholders marking where editable blocks go > - *Structurally locked* — inner blocks a user can edit the content of but cannot move, remove, or add siblings to ## Bib - **Source**: [Editable blocks inside the Custom HTML block](https://make.wordpress.org/core/2026/07/23/editable-blocks-inside-the-custom-html-block/) — Make WordPress Core, 2026-07-23 - **Reader doc**: [[3. Resources/Readwise/Articles/Editable blocks inside the Custom HTML block]] ## Author's thesis WordPress 7.1 lets a Custom HTML block interleave static markup with regular, editable — but structurally locked — inner blocks, and exposes the resulting shells as block variations; this creates a middle abstraction between free-form Custom HTML, a pattern, and a full custom block, letting developers (or AI-generated markup) ship fixed shells with narrowly scoped editable slots without a build pipeline. ## Key arguments (≤3) 1. **Editing rights and structural rights are now separable** — a user can change the words inside a slot without being able to rearrange, delete, or add to the shell around it. 2. **This is a new abstraction tier, not a replacement for existing ones** — it sits between free-form Custom HTML (fully open), a pattern (structurally alterable), and a custom block (fully controlled) — developers still have to choose the right one. 3. **"Immediately safe to edit" needs a narrower claim** — the dev note's own framing risks equivocating structural safety (users can't break the shell) with security or content-accuracy safety, which the feature does not address. ## Claim atoms ### [H1] Custom HTML gains editable block slots > [!quote] ID:rw_1036798921 > In WordPress 7.1, the Custom HTML block supports interleaving static HTML with regular, editable blocks. Where/why: opening feature statement — the core mechanism, useful when choosing a low-cost structured-content abstraction over a full custom block. ### [H2] Editable slots preserve fixed structure > [!quote] ID:rw_1036798922 > The static markup renders inert while the inner blocks are editable in place — but locked. Where/why: editor-behavior explanation — the source of the Permanent note below; separates content rights from structural rights. ### [H3] Variations package shells without custom blocks > [!quote] ID:rw_1036798923 > This lets you ship a fixed markup shell with editable slots as its own inserter item — no custom block needed. Where/why: variation-registration section — the development-cost claim: this closes a gap that used to require a custom block build. ## Permanent candidates - **Already captured**: [[3. Resources/Permanent Notes/Editable Slots Separate Content Rights From Structural Rights]] (created 2026-07-23 from this exact source, from atom H2 — do not duplicate). ## Processing checklist - [x] Connect into the relevant MOC — [[3. Resources/MOCs/Product & Startup Instincts MOC]] - [x] Cross-reference existing Permanent note instead of duplicating - [ ] Consider a Permanent note on the "structural safety ≠ security/accuracy safety" equivocation if a second source repeats the same conflation around AI-generated markup ## Links - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — a new middle-tier abstraction decision (pattern vs. variation vs. custom block) that's a product-design tradeoff, not just an implementation detail - [[3. Resources/Permanent Notes/Editable Slots Separate Content Rights From Structural Rights]] — the claim this source already generated, linked here rather than re-derived - [[3. Resources/MOCs/WordPress Platform Design MOC]] — applies-in: Joins the cluster on WordPress editor and block platform changes.