Editable blocks inside the Custom HTML block ![rw-book-cover](https://s.w.org/images/home/wordpress-default-ogimage.png) 🔗 **Source:** [Editable blocks inside the Custom HTML block](https://make.wordpress.org/core/2026/07/23/editable-blocks-inside-the-custom-html-block/) > [!note]+ Document Notes > tags: [wordpress-7-1, block-editor, custom-html-block, block-variations, ai-generated-markup] > author: WordPress Core contributors > source: Make WordPress Core > reference: https://make.wordpress.org/core/2026/07/23/editable-blocks-inside-the-custom-html-block/ > date created: > > # 🏷️ Title: Editable blocks inside the Custom HTML block > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor Appendix](#-refactor-appendix--editable-blocks-inside-the-custom-html-block) - [🧰 Template Library](#-template-library) ### 🔗 References - [Editable blocks inside the Custom HTML block](https://make.wordpress.org/core/2026/07/23/editable-blocks-inside-the-custom-html-block/) - [Editable inner blocks implementation](https://github.com/WordPress/gutenberg/pull/79115) - [Block variation innerContent support](https://github.com/WordPress/gutenberg/pull/79659) ## 📝 Summary - WordPress 7.1 lets a Custom HTML block contain regular editable blocks between static HTML fragments. - Inner blocks are editable but structurally locked: users cannot move, remove, or add siblings. The surrounding markup remains fixed and round-trips without changing. - `core/html` block variations gain `innerContent`, which maps static fragments around `innerBlocks` slots and exposes the result as a named inserter item. - Theme authors, plugin developers, agencies, content editors, and AI-tool builders are the main stakeholders. - Bottom line: developers can ship fixed markup shells with controlled editing slots without creating a custom block or build pipeline. ## 📖 Main Content - **Mixed content model:** The Custom HTML block can now interleave static markup and block delimiters. In the canvas, WordPress renders the shell but lets users edit the embedded blocks. - **Locked structure:** The inner blocks are content-editable but not structurally editable. Users cannot move or delete them, and cannot add sibling blocks. This preserves the author-defined shell. - **Round-trip behavior:** The full source remains available in the Edit HTML modal, and serialization preserves existing content. - **Variations:** A `core/html` variation can define `innerContent` as static fragments plus `null` placeholders aligned with `innerBlocks`. This creates a higher-level inserter item with constrained slots. - **AI angle:** Generated block markup can contain editable slots without a custom block. The source calls this immediately safe to edit, though safety here means structural editing constraints, not security validation or content accuracy. - **Scope:** `innerContent` applies only to `core/html` variations and is ignored for other blocks. ## 🗒️ Notes - The feature creates a middle ground between a free-form Custom HTML block, a pattern, and a custom block. - The shell belongs to the developer; the editable slot belongs to the content author. - A pattern normally lets users alter structure. This variation keeps the shell fixed. - The same design suits AI-generated components because the model can produce a shell while leaving selected text editable. - Security review still matters: editable blocks inside a Custom HTML block do not make arbitrary generated HTML trustworthy. - Accessibility review still matters: a locked shell can preserve good semantics or preserve a mistake users cannot repair. ## 📚 References - [Make WordPress Core dev note](https://make.wordpress.org/core/2026/07/23/editable-blocks-inside-the-custom-html-block/) - [Gutenberg PR 79115](https://github.com/WordPress/gutenberg/pull/79115) - [Gutenberg PR 79659](https://github.com/WordPress/gutenberg/pull/79659) ## 🗣️ Paraphrase - WordPress now treats the Custom HTML block as a container that can expose selected nested blocks for editing while leaving the raw shell inert. - Editors can change the intended content but cannot rearrange the component's structure. - Developers can register these shells as block variations using static fragments and slot markers. - This cuts the cost of shipping small structured components, but it also puts more responsibility on the shell author to get semantics, security, and responsive behavior right. ## 📰 Newsletter WordPress 7.1 gives the Custom HTML block a surprisingly useful new trick: fixed HTML can now wrap regular editable blocks. Think testimonial card, promo banner, or odd legacy component where the editor should change the words but not pull the structure apart. Block variations can package those shells as inserter items with no custom block or build step. It's a sharp tool, so test semantics and generated markup before calling it safe. [Read the dev note](https://make.wordpress.org/core/2026/07/23/editable-blocks-inside-the-custom-html-block/). ## ✅ Action Items #### DevRel - Demo a fixed shell with two editable slots and explain its limits. - Publish a comparison of Custom HTML variations, patterns, and custom blocks. - Collect agency use cases and failure reports. - Measure whether the feature reduces time to ship small structured components. #### OSPO - Document ownership for shared shell markup. - Add accessibility and security review to variation contribution policy. - Track third-party snippets and their licenses. - Encourage upstream examples with tests and provenance. #### Community - Maintainers: publish tested starter variations. - Contributors: add docs and edge-case tests. - Sponsors: support accessibility review for common shells. - Ecosystem: share examples that explain when a custom block remains the better choice. #### WordPress - Core: define serialization and invalid-block edge cases. - Core Performance: compare output and editor cost with patterns and custom blocks. - Core AI: constrain generated shells and label what remains unverified. - Core Program Team: coordinate documentation, security, accessibility, and release testing. - Mobile: confirm whether mixed Custom HTML editing is supported or safely degraded. - Playground: host copyable labs for variations and malformed markup. - Community: teach the feature in developer sessions. - Training: add a lesson on choosing the right block abstraction. - Marketing: describe the editing constraint accurately; avoid broad no-code claims. - Support: document recovery when a shell becomes invalid. - Design: define clear locked-state affordances. - Documentation: publish API shape, examples, and limitations. - Photos: no direct action. - TV: caption a short implementation demo. - Polyglots: test editable text and translation workflows inside fixed shells. - Accessibility: audit semantics, focus order, labels, and locked error recovery. - Meta: consider controlled shells for repeated WordPress.org interface content. - CLI: add examples for registering variation code in scaffolds. - Hosting: include the feature in 7.1 editor compatibility tests. - Tide: scan variation code for unsafe or invalid markup where feasible. - Openverse: test image and attribution blocks when placed in fixed shells. - Themes: publish semantic, responsive shell examples. - Plugins: review generated markup, capabilities, and sanitization. #### The WPOCC - Fund reusable, accessible variation examples and independent testing. - Sponsor docs that help small maintainers avoid unnecessary custom blocks. ### FAIR - Keep shell definitions portable and inspectable. - Record provenance for generated or copied markup. - Define operator rules for accepting third-party variations. ## 🧪 Hypotheses - Fixed shells with editable slots reduce development time for small content components. - Editors make fewer layout mistakes with locked slots than with equivalent patterns. - AI-generated shells increase adoption while also increasing invalid or inaccessible markup reports. - Clear lock affordances reduce confusion about why inner blocks cannot move. - Variations with two or fewer slots have lower support cost than more complex shells. ### 📊 Methodology - Build matched testimonial, banner, and card components as patterns, Custom HTML variations, and custom blocks. - Measure build time, editor task completion, structural errors, invalid-block rates, and accessibility defects. - Test with novice and experienced editors across desktop and mobile. - Audit generated examples for sanitization, semantics, responsive behavior, and translation. ### ❓ Questions - Which HTML elements and block combinations are unsupported? - How does invalid markup recovery work when the shell is locked? - Which capabilities or sanitization paths apply to generated shells? - Can users understand the difference between editable content and fixed structure? - How do revisions and reusable content interact with nested slots? ### 🔮 Future Research - Compare locked-slot editing with content-only editing in synced patterns. - Study whether the feature becomes a migration bridge from legacy HTML to native blocks. - Test AI generation with constrained schemas instead of free-form HTML. - Examine how fixed shells behave under theme changes and style variations. ### 💡 Implications - **Practice:** small components may no longer justify a custom block. - **Policy:** generated markup needs a review boundary even when editing is constrained. - **Security:** structural locks do not replace sanitization or capability checks. - **Education:** developers need a decision guide for pattern, variation, Custom HTML, and custom block. - **Funding:** reusable accessible shells are shared infrastructure worth supporting. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid grade 10–12 due to code and block-model terms. #### 👀 Visual learners - Present: code examples show shell and slot placement. - Improve: add an editor screenshot with locked and editable regions labeled. #### 🔊 Aural learners - Present: not applicable; no audio accompanies the captured article. - Improve: add a narrated two-minute demo. #### 🗣️ Verbal learners - Present: concise contrast with patterns. - Improve: define shell, slot, variation, and serialization. #### 🧩 Kinesthetic learners - Present: copyable variation code. - Improve: add a Playground exercise with a testimonial card. #### 🧠 Logical learners - Present: direct mapping between `innerContent` nulls and `innerBlocks`. - Improve: add a decision table for abstraction choice. #### 🧑‍🤝‍🧑 Social learners - Present: pull-request links for discussion. - Improve: provide review prompts for paired author-editor testing. #### 🧘‍♀️ Solitary learners - Present: short source and complete example. - Improve: add a self-check list for structure, semantics, and sanitization. #### 🌿 Naturalistic learners - Present: not applicable; no environmental frame. - Improve: compare maintenance cost across component lifecycles. ### 📊 Accessibility Assessment #### Screen reader semantics - Fixed shells can preserve landmarks and heading structure, but they can also lock semantic errors. Require a semantic audit. #### Keyboard navigation - Test focus order across static wrappers and nested interactive blocks. #### Contrast and readability - Shell authors control classes and styles, so test all supported themes and states. #### Text resizing and reflow - Verify that fixed wrappers reflow at 200% zoom and narrow widths. #### Media and captions - If slots accept media, require alt text, captions, and transcript support. #### Forms and interactions - Avoid placing form controls in shells without clear labels, errors, and target sizes. #### Standards reference - Check WCAG 2.2 AA criteria 1.3.1, 1.3.2, 1.4.10, 2.1.1, 2.4.3, 2.5.8, and 3.3.2. ### 🌍 DEIB Assessment #### Cultural breadth - The mechanism is locale-neutral, but examples should include multilingual and bidirectional text. #### Inclusive language - The source uses neutral technical language. #### Neurodiversity support - Locked structure can reduce accidental complexity, but unclear lock states can increase frustration. #### Representation - No human examples or audience research appear. #### Psychological safety - Recovery paths must let editors escape or report a broken shell without blame. ### ✅ Logical Validity #### Strong reasoning - The source gives a working syntax example, states the lock behavior, and contrasts variations with patterns. - It limits `innerContent` to `core/html`, preventing overgeneralization. #### Fallacies - The phrase “immediately safe to edit” risks equivocation. Structural safety is not security, accessibility, or factual safety. Fix by naming the specific safety property: users can edit slots without changing the shell. #### Tone of voice - Optimistic and practical, with a brief AI-oriented claim that deserves tighter boundaries. ### 🛡️ DARVO Analysis - Deny: not applicable. - Attack: not applicable. - Reverse victim/offender: not applicable. - The source is a feature explanation, not a conflict narrative. ## 🎯 Conclusion WordPress 7.1 creates a useful constrained-editing layer inside the Custom HTML block. The feature can cut development cost for small fixed components and provide controlled slots for generated markup. Teams should still review shell code for security, semantics, translation, responsive layout, and recovery before shipping it. ## 🔄 Refactor Appendix — Editable blocks inside the Custom HTML block ### 📚 Literature 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. **Context & use**: - Opening feature statement. - Use when choosing a low-cost structured-content abstraction. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://open/1036798921) <!-- atomicity: 1 idea ✓ --> ### [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. **Context & use**: - Editor behavior explanation. - Use when separating content rights from structural rights. **Tags**: #xref **Highlight**: [view highlight](readwise://open/1036798922) <!-- atomicity: 1 idea ✓ --> ### [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. **Context & use**: - Variation registration section. - Use when comparing development cost across block abstractions. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://open/1036798923) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates #### [P1] Editing rights can be narrower than structural rights **Claim**: A content surface can permit text changes while denying layout changes. **Evidence pointer**: [[#H2]] **Scope & conditions**: Applies to fixed shells with explicit slots; breaks when users must alter structure to complete the task. **Links**: - [[Bounded action spaces]] — because extends constrained editing. - [[Patterns versus custom blocks]] — because contrasts structural freedom with controlled slots. - [[AI-generated markup]] — because applies-in generated component shells. <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Test whether locked slots remain understandable with more than three editable regions — feature research #xref. ### → Things 3 - [ ] Build and accessibility-test one Custom HTML variation in Playground — WordPress 7.1 #things <!-- deep-read:sections end --> ## Highlights - In WordPress 7.1, the Custom HTML block supports interleaving static HTML with regular, editable blocks. ([View Highlight](https://make.wordpress.org/core/2026/07/23/editable-blocks-inside-the-custom-html-block/#interleaving)) - Note: H1 — Custom HTML becomes a fixed shell with editable block slots. - In the editor, the static markup renders inert while the inner blocks are editable in place — but locked: they can’t be moved, removed, or have siblings added. The surrounding structure stays intact. ([View Highlight](https://make.wordpress.org/core/2026/07/23/editable-blocks-inside-the-custom-html-block/#locked-slots)) - Note: H2 — Editing rights are narrower than structural rights. - Block variations now accept an innerContent field: an array of static HTML fragments where each null marks the position of the corresponding innerBlocks entry. This lets you ship a fixed markup shell with editable slots as its own inserter item — no custom block needed. ([View Highlight](https://make.wordpress.org/core/2026/07/23/editable-blocks-inside-the-custom-html-block/#variations)) - Note: H3 — Variations package fixed structure and editable slots without a custom block.