New Block Support in WordPress 7.1: Background Gradient  🔗 **Source:** [New Block Support in WordPress 7.1: Background Gradient](https://make.wordpress.org/core/2026/07/26/new-block-support-in-wordpress-7-1-background-gradient-background-gradient/) > [!note]+ Document Notes > tags: [block-supports, css-architecture, wordpress-7-1, theme-json, backwards-compatibility, style-engine] > author: Make WordPress Core > source: Make WordPress Core > reference: https://make.wordpress.org/core/2026/07/26/new-block-support-in-wordpress-7-1-background-gradient-background-gradient/ > date created: 2026-07-27 11:30 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: New Block Support in WordPress 7.1 — Background Gradient (`background.gradient`) > <!-- 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) ### 🔗 References - [The dev note](https://make.wordpress.org/core/2026/07/26/new-block-support-in-wordpress-7-1-background-gradient-background-gradient/) - [Gutenberg issue #32787](https://github.com/WordPress/gutenberg/issues/32787) and [PR #75859](https://github.com/WordPress/gutenberg/pull/75859) - [WPBeginner — What's Coming in WordPress 7.1](https://www.wpbeginner.com/news/whats-coming-in-wordpress-7-1-features-screenshots/) — the user-facing companion in this reading set - [MDN — `background-image`](https://developer.mozilla.org/en-US/docs/Web/CSS/background-image) and [`background` shorthand](https://developer.mozilla.org/en-US/docs/Web/CSS/background) - [Block supports reference](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-supports/) ## 📝 Summary - **What happened.** WordPress 7.1 adds a `background.gradient` block support, giving blocks a gradient control in the Background panel of the block inspector. Unlike the existing `color.gradient` support, it can be combined with a background image so both render together. Group, Accordion, Pullquote, Post Content, and Quote opt in for 7.1. - **Why it matters.** The root cause is a genuinely instructive CSS detail. The old support wrote gradients through the `background` **shorthand**, which resets every background property including `background-image` — so a block could have a gradient *or* an image, never both. The new support writes through the `background-image` **longhand**, letting the style engine emit both as comma-separated values in a single declaration. A years-old user-facing limitation traced to one shorthand-versus-longhand choice. - **Key stakeholders.** Block developers deciding whether to opt in; theme authors who can now set gradients through the `background` styles group in `theme.json`; anyone who has fought the gradient-over-hero-image problem; and core, which is laying groundwork for eventually consolidating two gradient systems into one. - **Risks and tradeoffs.** The release ships with **two gradient supports coexisting** — `color.gradient` and `background.gradient` — which is a real if temporary API surface duplication. The note is explicit that migration is planned but not part of this change. There's also a security-relevant change: `safecss_filter_attr()` was loosened to permit combined gradient + `url()` values, which is necessary for the feature and worth understanding. - **Bottom line.** A model dev note — states the problem, the mechanism, the opt-in, the cascade, the security implication, the relationship to the existing support, and the backwards-compatibility position, in about 1,200 words of actual content. The interesting engineering lesson is that shorthand properties are destructive, and that choosing longhand is what makes composition possible. ## 📖 Main Content **What's being added.** A new `background.gradient` block support, surfacing a gradient control in the Background panel of the block inspector — sitting next to the existing background image control rather than in the Color panel. The headline capability: unlike the existing gradient support, this one can be combined with a background image so the two render together. Tracked at Gutenberg issue #32787 and PR #75859. **The background — and the actual root cause.** This is the part worth reading carefully, because it explains a long-standing limitation with a specific technical mechanism rather than hand-waving. Until now, the only way to apply a gradient to a block was through the Color panel's `color.gradient` support. That value is stored at `style.color.gradient` and rendered as a `background` CSS **shorthand**. The consequence follows directly from how CSS shorthands work: **the `background` shorthand resets every background property, including `background-image`.** So a gradient set through `color.gradient` would conflict with and override any background image on the same block. A block could show a gradient or an image, but not both. That's a clean causal explanation. The user-facing symptom — "why can't I put a gradient over my hero image?" — traces to a single implementation decision about which CSS property to write. It's a good reminder that shorthand properties are destructive by design, and that the destruction is easy to overlook when you're generating CSS programmatically. **What changed — the mechanism.** The new support registers separately and stores its value at `style.background.gradient`, distinct from the existing `style.color.gradient`. Two separate storage locations, which matters for the backwards-compatibility story. The key difference is stated plainly: **the new support renders through the `background-image` longhand property instead of the `background` shorthand.** Because it avoids the shorthand, it doesn't reset the other background properties. The style engine can then output the gradient and any background image as comma-separated values in a single `background-image` declaration: ```css background-image: linear-gradient( 135deg, #000 0%, #fff 100% ), url( 'https://example.com/image.jpg' ); ``` The gradient layers over the image and both render. That's the entire fix, and it's elegant — the capability wasn't blocked by anything architectural, just by writing to the wrong property. **Key behaviors documented.** Four, each addressing a question a developer would actually ask: - The control appears in the Background panel, next to the existing background image control — so it's discoverable where you'd expect it, alongside the thing it composes with. - **When `background.gradient` is enabled for a block, the gradient tab in the Color panel is suppressed** to avoid duplicate controls. This is the detail that prevents a confusing UI where the same block offers two gradient controls that behave differently. Good interface hygiene, and it's the kind of thing that's easy to forget when adding a parallel system. - Gradient preset slugs resolve to CSS custom properties, e.g. `var( --wp--preset--gradient--vivid-cyan-blue )`, keeping theme presets working through the new path. - When only a gradient is set with no image, it renders on its own as the `background-image` value — so the simple case degrades correctly. **How to opt in.** Block developers add `gradient` under the `background` support in `block.json`, alongside `backgroundImage`, with matching `__experimentalDefaultControls` entries to surface the controls by default. In 7.1, **Group, Accordion, Pullquote, Post Content, and Quote** opt in. That's a conservative initial set — mostly container and quotation blocks where layered backgrounds make design sense — rather than a blanket rollout, which is the right call for a new support. **Theme-level configuration.** In `theme.json`, the gradient is set through the `background` styles group, either at the root or per block. The example shows a root-level linear gradient and a `core/group` override using a preset reference (`var:preset|gradient|vivid-cyan-blue`). Crucially: **block-level values set in the editor override theme defaults, following the same cascade as other block supports.** Consistency with the existing cascade is the important claim here — a new support that invented its own precedence rules would be a genuine problem, and the note explicitly says it doesn't. **How it works — front end.** Server-side rendering in the background block support reads the gradient value and passes it, with any background image, to the style engine. The engine merges them into one comma-separated `background-image` value and injects it as an inline style on the block wrapper. One detail with practical consequences: **serialization for the image and the gradient is checked independently**, so a block can skip one while still rendering the other. That means the two aren't coupled — you're not forced into an all-or-nothing serialization path, which matters for blocks that support one but not the other. **How it works — sanitization, and the security-relevant change.** Previously, `safecss_filter_attr()` stripped a `background-image` value that mixed a gradient function with a `url()`. In 7.1, **`safecss_filter_attr()` is updated to allow these combined gradient + `url()` values**, so no additional filter is required. This is the item most worth flagging. The sanitizer's job is constraining what CSS can appear in user-supplied content, and this change widens what it permits in a property that accepts `url()` — historically a sensitive construct. The note presents it as a straightforward enabling change and doesn't discuss the security reasoning, which is a gap given that `safecss_filter_attr()` exists specifically as a security boundary. The change is almost certainly fine and narrowly scoped; the dev note simply doesn't show the work. **Relationship to `color.gradient`.** Stated clearly: `background.gradient` is a **separate** support. Existing blocks using `color.gradient` are unchanged and continue to work exactly as before. Then the forward-looking part: this new support **lays the groundwork for eventually migrating gradient handling from `color.gradient` to `background.gradient` across blocks**, giving a single more capable background styling system — and **that migration is not part of this change.** That's honest architectural signposting. It tells developers where this is heading without pretending the destination has been reached, and it explains why two overlapping supports will coexist for now. The temporary duplication is a deliberate cost paid for a non-breaking path. **Backwards compatibility.** The changes are additive. No existing blocks break, no action required for most blocks and themes, and blocks that don't opt in behave exactly as before including any current `color.gradient` use. **Contested and uncertain.** No timeline is given for the migration, so how long two gradient systems coexist is open. The security reasoning behind the sanitizer change isn't shown. And there's no discussion of what happens to blocks that opt into `background.gradient` while their themes still target `color.gradient` in `theme.json` — presumably handled by the cascade, but not stated. ## 🗒️ Notes Not a transcript and contains no timestamps, so no timestamped subheadings. Dense notes follow, in document order. - **What's added.** A `background.gradient` block support giving blocks a gradient control in the Background panel of the block inspector. Combinable with a background image so both render together. - **Tracking.** Gutenberg issue #32787, PR #75859. - **The prior state.** The only way to apply a gradient was the Color panel's `color.gradient`, stored at `style.color.gradient` and rendered as a `background` CSS shorthand. - **The root cause, stated precisely.** The `background` shorthand **resets every background property, including `background-image`.** A gradient set through `color.gradient` therefore conflicted with and overrode any background image on the same block — gradient or image, never both. - **Why that's a good explanation.** A years-old user-facing limitation traced to a single choice of which CSS property to write. Shorthands are destructive by design, and that's easy to overlook when generating CSS programmatically. - **New storage location.** Value stored at `style.background.gradient`, separate from `style.color.gradient`. Two distinct locations, which underpins the backwards-compatibility story. - **The mechanism.** Renders through the `background-image` **longhand** instead of the `background` shorthand. Avoiding the shorthand means other background properties aren't reset. - **The output.** Style engine emits gradient and image as comma-separated values in one declaration — `background-image: linear-gradient(...), url(...)`. Gradient layers over image. - **Behavior — placement.** Control appears in the Background panel next to the existing background image control. Discoverable alongside what it composes with. - **Behavior — duplicate suppression.** When `background.gradient` is enabled for a block, **the gradient tab in the Color panel is suppressed** to avoid duplicate controls. Prevents a confusing UI offering two gradient controls that behave differently. - **Behavior — presets.** Gradient preset slugs resolve to CSS custom properties, e.g. `var( --wp--preset--gradient--vivid-cyan-blue )`. Theme presets keep working through the new path. - **Behavior — gradient alone.** With no image set, the gradient renders on its own as the `background-image` value. Simple case degrades correctly. - **Opt-in.** Add `gradient` under `background` in `block.json`, with matching `__experimentalDefaultControls` entries to surface controls by default. - **Blocks opting in for 7.1.** Group, Accordion, Pullquote, Post Content, Quote. Conservative initial set — container and quotation blocks where layered backgrounds make design sense. - **theme.json configuration.** Gradient set through the `background` styles group, at root or per block. Example shows a root linear gradient plus a `core/group` override using `var:preset|gradient|vivid-cyan-blue`. - **Cascade consistency.** Block-level editor values override theme defaults, **following the same cascade as other block supports.** A new support inventing its own precedence would be a real problem; the note explicitly says it doesn't. - **Front-end rendering.** Server-side rendering reads the gradient value, passes it with any background image to the style engine, which merges them into one comma-separated `background-image` and injects it as an inline style on the block wrapper. - **Independent serialization.** Image and gradient serialization are checked **independently**, so a block can skip one while still rendering the other. Not an all-or-nothing path. - **The sanitizer change — worth flagging.** `safecss_filter_attr()` previously **stripped** `background-image` values mixing a gradient function with `url()`. In 7.1 it is **updated to allow** combined gradient + `url()` values, so no additional filter is required. - **What the note doesn't show.** `safecss_filter_attr()` exists as a security boundary constraining CSS in user-supplied content. The change widens what it permits in a property accepting `url()`. Presented as straightforward enabling; the security reasoning isn't discussed. - **Separate from `color.gradient`.** Existing blocks using `color.gradient` are unchanged and continue to work exactly as before. - **The stated direction.** Lays groundwork for eventually migrating gradient handling from `color.gradient` to `background.gradient` across blocks, for a single more capable background styling system — **but that migration is not part of this change.** - **Honest signposting.** Tells developers where this is heading without claiming arrival, and explains why two overlapping supports coexist for now. Temporary duplication is a deliberate cost for a non-breaking path. - **Backwards compatibility.** Additive. No existing blocks broken, no action required for most blocks and themes, non-opting blocks unchanged including current `color.gradient` use. ## 📚 References - [Make/Core — background.gradient dev note](https://make.wordpress.org/core/2026/07/26/new-block-support-in-wordpress-7-1-background-gradient-background-gradient/) - [Gutenberg issue #32787](https://github.com/WordPress/gutenberg/issues/32787) — the originating issue - [Gutenberg PR #75859](https://github.com/WordPress/gutenberg/pull/75859) — the implementation - [WPBeginner — What's Coming in WordPress 7.1](https://www.wpbeginner.com/news/whats-coming-in-wordpress-7-1-features-screenshots/) — user-facing coverage of the same feature - [MDN — `background-image`](https://developer.mozilla.org/en-US/docs/Web/CSS/background-image) — the longhand property that makes composition possible - [MDN — `background` shorthand](https://developer.mozilla.org/en-US/docs/Web/CSS/background) — and its resetting behavior, the root cause - [Block supports reference](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-supports/) - [theme.json styles reference](https://developer.wordpress.org/block-editor/reference-guides/theme-json-reference/theme-json-living/#styles) - [`safecss_filter_attr()`](https://developer.wordpress.org/reference/functions/safecss_filter_attr/) — the sanitizer modified by this change ## 🗣️ Paraphrase - WordPress 7.1 introduces a `background.gradient` block support that places a gradient control in the Background panel of the block inspector and, unlike the existing gradient support, can coexist with a background image. - Previously the only route to a block gradient was the Color panel's `color.gradient`, stored under `style.color.gradient` and written out as a CSS `background` shorthand. - Because the `background` shorthand resets every background property including `background-image`, any gradient applied this way overrode a background image on the same block, allowing one or the other but never both. - The new support stores its value separately at `style.background.gradient` and renders through the `background-image` longhand rather than the shorthand. - Avoiding the shorthand means other background properties survive, so the style engine can emit the gradient and any image together as comma-separated values in a single `background-image` declaration, layering the gradient over the image. - The control sits beside the existing background image control, and enabling it suppresses the Color panel's gradient tab so no duplicate controls appear. - Gradient presets resolve to CSS custom properties, and a gradient set without an image renders on its own. - Blocks opt in by adding `gradient` under the `background` support in `block.json`, with default control entries; Group, Accordion, Pullquote, Post Content, and Quote do so in 7.1. - Themes can set the gradient through the `background` styles group in `theme.json`, at the root or per block, with block-level editor values overriding theme defaults according to the same cascade as other supports. - On the front end, server-side rendering passes the gradient and any image to the style engine, which merges them into one declaration injected as an inline style on the block wrapper. - Serialization of the image and the gradient is evaluated independently, so a block may render one without the other. - The `safecss_filter_attr()` sanitizer, which previously removed `background-image` values combining a gradient function with a `url()`, now permits them, removing the need for an additional filter. - The new support is entirely separate from `color.gradient`, and blocks relying on the older support continue to behave as they always have. - It also establishes the basis for eventually consolidating gradient handling under a single background styling system, though that migration is explicitly not part of this release. - All changes are additive, breaking nothing and requiring no action from most blocks or themes. ## 📰 Newsletter **A years-old WordPress limitation turns out to have been one CSS shorthand.** If you've ever tried to put a gradient overlay on a hero image in a Group block and found that setting the gradient wiped out your image, WordPress 7.1 fixes it — and the *why* is the genuinely instructive part. The old gradient support wrote its value through the CSS `background` **shorthand**. And shorthands are destructive: setting `background` resets *every* background property, including `background-image`. So the gradient didn't conflict with your image in some subtle cascade way. It erased it. Gradient or image, never both. The new `background.gradient` support writes through the `background-image` **longhand** instead. Nothing gets reset, and the style engine can emit both as comma-separated values in one declaration: `background-image: linear-gradient( 135deg, #000 0%, #fff 100% ), url( 'hero.jpg' );` That's the whole fix. The capability was never blocked by architecture — just by writing to the wrong property. It's a good reminder for anyone generating CSS programmatically: shorthands are convenient and they clobber things you didn't mention. **What you need to know as a developer:** Opt in via `block.json` by adding `gradient` under the `background` support. **Group, Accordion, Pullquote, Post Content, and Quote** opt in for 7.1 — a conservative set, sensibly limited to blocks where layered backgrounds actually make design sense. Themes configure it through the `background` styles group in `theme.json`, root or per-block, and preset slugs resolve to custom properties as you'd expect. Block-level editor values override theme defaults following the **same cascade as every other block support** — which is the boring detail that matters most, because a new support inventing its own precedence rules would be a genuine mess. Nice interface detail: enabling `background.gradient` on a block **suppresses the gradient tab in the Color panel**, so users don't get two gradient controls that behave differently. Easy thing to forget when you add a parallel system, and they didn't. **Two things worth a second look.** First, `safecss_filter_attr()` has been **loosened** to permit `background-image` values that mix a gradient function with a `url()` — it used to strip those. That's necessary for the feature to work, and it's a sanitizer whose entire job is constraining CSS in user-supplied content. The note states the change and doesn't show the security reasoning. Almost certainly fine and narrowly scoped, but if you're the person who reviews that boundary, go read the PR. Second, **7.1 ships with two gradient supports coexisting.** `color.gradient` is untouched and keeps working. The note is explicit that this lays groundwork for eventually consolidating everything under `background.gradient` — and equally explicit that the migration isn't part of this change. That's honest signposting rather than pretending the destination has been reached, and the temporary API duplication is a deliberate price for a non-breaking path. Everything here is additive. Nothing breaks, nothing needed from most themes and blocks. If you want the user-facing version of this feature, WPBeginner's 7.1 preview covers it in one line as "background gradients and images work together." True, and it tells you nothing about why it didn't before. Read the dev note. ## ✅ Action Items #### DevRel - Developer advocacy: this dev note is a good teaching artifact for the shorthand-versus-longhand lesson, which generalizes far beyond WordPress to anyone generating CSS programmatically. - Education: worth a short piece on why CSS shorthands are destructive, using this as the worked example — the lesson is broadly applicable and this is an unusually clean case. - Developer experience: none applicable beyond the opt-in guidance the note already provides. - Developer marketing: none applicable to this source. - Community management: none applicable to this source. - Internal/external/cross-project: none applicable to this source. #### OSPO - Policy & Governance: none applicable to this source. - License Compliance: none applicable to this source. - Security Management: **the item worth attention.** `safecss_filter_attr()` is a security boundary and it has been widened to permit gradient + `url()` combinations in `background-image`. Review the PR for the sanitization reasoning before assuming it's fully constrained, particularly for sites accepting block content from untrusted contributors. - Software Inventory: none applicable to this source. - Developer Support: none applicable to this source. - Community Engagement: none applicable to this source. - Strategic Alignment: none applicable to this source. #### Community - Maintainers: if you maintain container-style blocks, evaluate opting into `background.gradient` — the initial core set signals the intended use case. - Contributors: none applicable to this source. - Sponsors: none applicable to this source. - Ecosystem: none applicable to this source. #### WordPress - Core: the coexistence of `color.gradient` and `background.gradient` is deliberate and temporary; tracking the eventual migration publicly would help third-party block authors plan. - Core Performance: none applicable to this source. - Core AI: none applicable to this source. - **Core Program Team:** the "ship the new support, defer the migration" pattern is a reusable approach for API evolution without breakage — worth documenting as a pattern rather than a one-off. - Mobile: none applicable to this source. - Playground: a Playground demo showing gradient-over-image would communicate this faster than the code samples. - Community: none applicable to this source. - Training: fold into any block-supports lesson material; the opt-in and cascade behavior are both teachable. - Marketing: none applicable to this source. - Support: expect questions about why the Color panel's gradient tab disappeared on certain blocks — the suppression behavior is correct but will look like a missing feature. - Design: **relevant.** Gradient-over-image is most commonly used to make text legible over photography. That's a contrast problem, and the feature now makes it easy to do without making it easy to verify. - Documentation: document `background.gradient` in the block supports reference and the `background` styles group in the `theme.json` reference — both are new surface. - Photos: none applicable to this source. - TV: none applicable to this source. - Polyglots: none applicable to this source. - Accessibility: **worth a deliberate look.** The primary use case is overlaying gradients on images to improve text legibility, which is a WCAG 1.4.3 contrast concern. Making the overlay easy doesn't make the resulting contrast correct, and nothing in the editor checks it. Guidance — or a contrast check on text over composed backgrounds — would be a genuine contribution. - Meta: none applicable to this source. - CLI: none applicable to this source. - Hosting: none applicable to this source. - Tide: none applicable to this source. - Openverse: none applicable to this source. - Themes: `theme.json` gains a `background` styles group for gradients at root and block level — update theme documentation and test matrices. - Plugins: block authors should know that opting in suppresses the Color panel gradient tab, which changes the UI their users see. #### The WPOCC - Programs: none applicable to this source. - Projects: none applicable to this source. - Funding experiments: none applicable to this source. ### FAIR - Technical independence: none applicable to this source. - Policies and covenants: none applicable to this source. - Productized governance artifacts: none applicable to this source. ## 🧪 Hypotheses 1. **Longhand generation prevents composition bugs.** CSS-generating systems that write longhand properties produce measurably fewer property-clobbering defects than those writing shorthands, across comparable feature surface. 2. **Duplicate-control suppression prevents confusion.** Users encountering a single gradient control complete gradient-setting tasks faster and with fewer errors than users presented with two differently-behaving controls. 3. **Gradient-over-image use is contrast-motivated.** The dominant real-world use of composed gradient-plus-image backgrounds is improving text legibility, not decoration. 4. **Easy overlays don't produce accessible contrast.** Sites using composed gradient-over-image backgrounds fail WCAG 1.4.3 for text over those backgrounds at a rate comparable to or higher than sites using images alone. 5. **Deferred migration extends indefinitely.** API duplications introduced with a stated intent to consolidate persist substantially longer than initially anticipated, measured across core's history of parallel supports. 6. **Dev note quality predicts adoption.** Block supports documented with problem, mechanism, opt-in, and cascade see faster third-party adoption than those documented with opt-in alone. ### 📊 Methodology - **H1 (longhand vs shorthand).** Retrospective defect analysis across CSS-generating codebases, coding bug reports for property-clobbering symptoms and classifying the generation approach. Hard to get clean comparison groups, so a within-project analysis across features — some shorthand-generated, some longhand — controls better than cross-project comparison. This particular issue (#32787) is one data point and its age is informative. - **H2 (control suppression).** Usability study with two interface conditions: single gradient control versus both Color-panel and Background-panel controls present. Measure task completion time, error rate, and which control participants reach for first. Small, cheap, and directly answers whether the suppression decision was worth the implementation cost. - **H3 (use motivation).** Content analysis of sites using composed backgrounds, classifying each instance as text-legibility-motivated or purely decorative by examining whether text overlays the composed area. Sample from the plugin/theme demo corpus plus a crawl of 7.1-era sites once adoption exists. - **H4 (contrast outcomes) — the one worth running.** Automated contrast scanning of text over composed gradient-plus-image backgrounds, compared against text over plain images and text over solid colors. Contrast over a gradient-plus-photo background is genuinely hard to compute — the effective background varies per pixel — so the method needs a defined sampling approach (worst-case pixel under the text bounding box is the defensible choice). That measurement difficulty is itself the finding: if it's hard to compute automatically, editors can't warn users either. - **H5 (migration duration).** Historical analysis of core's parallel API surfaces — experimental prefixes, deprecated-but-retained supports — measuring stated intent to consolidate against actual elapsed time to consolidation. Straightforward archival work with a useful predictive payoff. - **H6 (documentation and adoption).** Correlate dev note completeness (coded against a rubric: problem stated, mechanism explained, opt-in shown, cascade described, compatibility addressed) with third-party block adoption rates over the following two releases. Confound: supports differ in inherent usefulness, so control for the number of core blocks opting in as a proxy. ### ❓ Questions - What's the security reasoning behind loosening `safecss_filter_attr()`? The function exists to constrain CSS in user-supplied content, and it now permits `url()` alongside gradient functions in `background-image`. Almost certainly fine and narrowly scoped, but the note states the change without showing the analysis. - How long will two gradient supports coexist? The migration is signposted with no timeline, and core has a history of parallel surfaces outliving their stated temporariness. - What happens when a block opts into `background.gradient` but its theme still sets `color.gradient` in `theme.json`? Presumably resolved by the cascade, but the interaction isn't stated and it's the obvious edge case. - Does the Color-panel suppression confuse existing users? Correct behavior, but a gradient control disappearing from where someone learned to find it looks like a regression. - Is contrast over a composed background checkable at all? The primary use case is text legibility over photography. Effective contrast varies per pixel across a gradient-over-image composite, which makes automated checking genuinely hard — and if tooling can't compute it, neither can the person using the control. - Why these five blocks? Group, Accordion, Pullquote, Post Content, Quote is a sensible-looking set, but the selection criteria aren't stated, which leaves third-party authors guessing about intended scope. - Does independent serialization create any state where the rendered result diverges from the editor preview? Image and gradient are serialized independently, which is flexible, and flexibility in rendering paths is where preview/front-end mismatches usually live. ### 🔮 Future Research - **Contrast verification over composite backgrounds.** A genuinely open technical problem: computing effective contrast for text over a gradient-plus-image composite, and whether an editor can warn usefully. This gets more pressing as composition features ship. - **API duplication lifetimes in core.** How long parallel supports actually coexist versus the intent stated when they're introduced, and what predicts consolidation. - **Programmatic CSS generation patterns.** Shorthand-versus-longhand as a general design principle for style engines, with this issue as a case study. - **Dev note effectiveness.** Whether documentation completeness measurably affects third-party adoption of block supports — testable and useful for core's documentation practice. - **Design-feature accessibility coupling.** A pattern worth studying across this release: features that make an accessibility-adjacent outcome easier to *attempt* (gradient overlays for legibility, focus-state styling) without making it easier to *verify*. - **Block support adoption curves.** How quickly third-party blocks adopt new supports after core blocks opt in, which would inform how core signals intended scope. ### 💡 Implications - **Practice.** The transferable engineering lesson is about programmatic CSS generation: shorthands clobber properties you never mentioned, and choosing longhand is what makes composition possible. Anyone writing a style engine, a CSS-in-JS layer, or a block support should default to longhand unless there's a reason not to. This dev note is an unusually clean worked example of the cost of getting that wrong. - **Policy.** The "ship the capability, defer the migration" pattern is good API evolution practice and worth naming as such. It accepts temporary duplication to avoid breakage, and it signposts direction honestly rather than either shipping a breaking change or pretending the old surface is fine forever. The risk is that deferred migrations slip indefinitely, which argues for tracking them publicly with owners. - **Security.** `safecss_filter_attr()` is a sanitization boundary and it has been widened. Sites accepting block content from untrusted contributors — multi-author publications, membership sites with user-generated content — should understand what the loosened filter now permits. The change is almost certainly correct and narrowly scoped; the point is that a security-relevant loosening deserves the reasoning stated in the dev note rather than discovered in the PR. - **Education.** Two teachable items. The shorthand/longhand mechanism is a genuine CSS lesson with a real consequence attached, which is far more memorable than the abstract version. And the dev note itself is a model of the form — problem, mechanism, opt-in, cascade, security note, relationship to existing API, compatibility position — worth showing to anyone learning to write technical documentation. - **Funding models.** Not applicable to this source. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid Grade 11.2; Flesch Reading Ease 43.1 ("difficult"), computed on the ~1,200-word dev-note body excluding the site's inline glossary interjections. Appropriately technical for its audience. The measured score is inflated somewhat by the Make network's automatic glossary expansions, which splice definitions mid-sentence and wreck sentence-length statistics — the actual prose is cleaner than the number suggests. #### 👀 Visual learners - Present: a rendered CSS example showing the comma-separated `background-image` output, plus JSON samples for both `block.json` and `theme.json`. The code samples carry the explanation effectively. - Improve: no before/after visual of the actual rendered result. For a feature whose entire point is what appears on screen — a gradient layered over an image — a single screenshot would communicate faster than the CSS. No diagram of the cascade relationship between theme and block values either. #### 🔊 Aural learners - Present: nothing; text-only dev note. - Improve: not really expected for the format, though core dev notes are exactly the content that gets discussed in Slack meetings and could reasonably be summarized in release-cycle audio. #### 🗣️ Verbal learners - Present: strong. The causal explanation is stated in plain sentences before any code appears — "the background shorthand resets every background property, including background-image" is the whole diagnosis in one line, and everything follows from it. - Improve: the Make network's inline glossary expansions are actively harmful to reading flow, interrupting sentences with definitions of "core," "bug," "block," "CSS," "GitHub," "conflict," "filter," and "migration." Someone reading a dev note about CSS block supports does not need "CSS" defined mid-sentence, and the interruption breaks exactly the causal chains the note constructs carefully. #### 🧩 Kinesthetic learners - Present: excellent. Copy-pasteable `block.json` and `theme.json` snippets, a named list of blocks that opt in, and linked issue and PR for reading the implementation. - Improve: no test case or Playground link. For a visual feature, a runnable demo would be more useful than the code samples, and the friction between "here's the JSON" and "here's what it looks like" is left to the reader. #### 🧠 Logical learners - Present: the best dimension, and the reason this note is worth reading. Clean structure: problem → root cause → mechanism → behaviors → opt-in → cascade → rendering → sanitization → relationship to prior API → compatibility. Each section answers a question the previous one raises, and the causal chain from shorthand-resets-properties to gradient-overrides-image to use-longhand-instead is airtight. - Improve: the sanitization section states a change to a security boundary without stating why it's safe. That's the one place where a logical reader following the chain hits an assertion instead of an argument. #### 🧑‍🤝‍🧑 Social learners - Present: issue and PR are linked directly, providing entry points for discussion and review. Published on a site whose whole purpose is contributor communication. - Improve: no indication of who to ask about the sanitization change or where the migration timeline is being discussed. For a note that explicitly signposts future work, pointing at where that work is tracked would help people participate. #### 🧘‍♀️ Solitary learners - Present: fully self-contained. A developer can read this once and correctly implement the opt-in without further reference. - Improve: little to fault for the format. The linked issue and PR cover deeper independent investigation. #### 🌿 Naturalistic learners - Present: minimal, as expected for an API note. - Improve: the closest available framing is architectural evolution — an old system coexisting with its successor during a managed transition rather than a hard cutover. That's a genuinely organic pattern and the note describes it well without naming it as such. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: standard heading structure with clear section divisions; code samples in distinguishable blocks. - Improve: the inline glossary expansions are a real screen reader problem, not merely a stylistic one — definitions spliced mid-sentence produce confusing linear reading order, and a listener encounters "the WordPress core Core Core is the set of software required to run WordPress" as spoken text. Maps to WCAG 2.2 AA 1.3.2 Meaningful Sequence, 1.3.1 Info and Relationships. #### Keyboard navigation - Present: standard content page with no author-introduced interactive components. - Improve: the glossary terms are interactive tooltips; whether they're keyboard-reachable and dismissible is worth checking. Maps to WCAG 2.2 AA 2.1.1 Keyboard, 1.4.13 Content on Hover or Focus. #### Contrast and readability - Present: standard Make network theming. - Improve: nothing content-specific. Maps to WCAG 2.2 AA 1.4.3 Contrast (Minimum). #### Text resizing and reflow - Present: prose reflows normally. - Improve: code blocks containing long CSS and JSON lines are the usual horizontal-scroll risk at high zoom. Maps to WCAG 2.2 AA 1.4.10 Reflow. #### Media and captions - Present: not applicable — no audio, video, or images. - Improve: a rendered example image would help comprehension substantially, and would then need alt text describing the layered result. #### Forms and interactions - Present: not applicable to the note body. - Improve: none. #### Standards reference - Aggregate: the note's own accessibility issue is the glossary tooltip system (1.3.2, 1.4.13), which is a Make network platform decision rather than an author choice — though authors are the ones whose careful causal explanations get interrupted by it. **The more consequential accessibility content is the subject matter**: the dominant use of gradient-over-image is making text legible over photography, which is a 1.4.3 contrast concern. This feature makes the overlay trivially easy to apply and provides no way to verify the resulting contrast, and effective contrast over a gradient-plus-photo composite is genuinely difficult to compute. That difficulty is the finding — if tooling can't check it, neither can the person using the control. ### 🌍 DEIB Assessment #### Cultural breadth - Present: purely technical content with no cultural or regional dimension. - Improve: not applicable in any meaningful sense for an API note. #### Inclusive language - Present: neutral, precise, and free of idiom — the register is descriptive throughout, which travels well for the substantially non-native-English-speaking contributor base. - Improve: the glossary expansions ostensibly exist to aid newcomers, and they define genuinely basic terms while leaving the actually specialized ones — "block supports," "style engine," "serialization," "longhand," "shorthand" — unexplained. The accessibility aid is aimed at the wrong vocabulary. #### Neurodiversity support - Present: strong underlying structure — short sections with descriptive headings, a consistent problem-then-solution pattern, code samples clearly separated from prose, and a predictable progression. - Improve: the mid-sentence glossary interruptions are a genuine processing burden, breaking working memory on sentences that carry the note's causal argument. A reader tracking "the shorthand resets every background property" has that chain interrupted by a definition of "CSS." Terminal or hover-only definitions would preserve the structure the author built. #### Representation - Present: not applicable — no people, case studies, or imagery. - Improve: the implicit reader is a block developer comfortable with `block.json`, `theme.json`, CSS specificity, and server-side rendering. Appropriate for the venue, and the note doesn't pretend otherwise. #### Psychological safety - Present: notably good in a quiet way. The backwards-compatibility section states plainly that nothing breaks and no action is required for most blocks and themes, which is exactly what a developer reading a dev note wants to know first about their existing work. The explicit "that migration is not part of this change" prevents anticipatory anxiety about a future breaking change. - Improve: the sanitizer loosening is the one item that might warrant more reassurance than it gets, since a security-relevant change stated without reasoning invites more worry than a stated rationale would. ### ✅ Logical Validity #### Strong reasoning - **A complete and correct causal chain.** The note establishes that the `background` shorthand resets all background properties, that `color.gradient` renders through that shorthand, and that this necessarily means gradient and image cannot coexist. Each step follows from the last, and the conclusion — use the longhand instead — is derived rather than asserted. This is the strongest piece of technical explanation in anything I've processed this batch. - **Root-cause explanation over symptom description.** The note could have said "gradients and images now work together" and stopped. Instead it explains *why* they didn't, which lets a reader generalize the lesson to other CSS-generation contexts. That's the difference between documentation and teaching. - **Anticipated UI consequence, addressed.** Recognizing that a parallel gradient control would produce two differently-behaving controls, and suppressing the Color-panel tab when the new support is enabled, is reasoning about the interface consequence of an API decision rather than only the API. - **Explicit cascade consistency.** Stating that block-level values override theme defaults "following the same cascade as other block supports" preempts the reasonable worry that a new support might invent its own precedence rules. Naming the consistency is what makes it verifiable. - **Honest scoping of future work.** "This new support also lays the groundwork for eventually migrating... That migration is not part of this change" gives direction without overclaiming, and explains the temporary duplication as deliberate rather than accidental. - **Independent serialization noted.** Flagging that image and gradient serialization are checked separately, so a block can skip one while rendering the other, documents a non-obvious behavior a developer would otherwise discover by surprise. #### Fallacies - **Unargued security assertion.** "In WordPress 7.1, `safecss_filter_attr()` is updated to allow these combined gradient + url() values, so no additional filter is required." **Weakness:** `safecss_filter_attr()` exists specifically as a security boundary constraining what CSS may appear in user-supplied content, and this widens what it permits in a property that accepts `url()`. The change is stated as a straightforward enabling step with no discussion of why the loosening is safely bounded. In a note that otherwise explains its reasoning at every step, this is the one place an assertion substitutes for an argument. **Fix:** one or two sentences on what the updated filter still rejects, and what the sanitization analysis found. - **Unstated selection criteria.** Group, Accordion, Pullquote, Post Content, and Quote opt in, with no explanation of why those five. **Weakness:** third-party block authors deciding whether to opt in have no stated principle to reason from, only an example set to pattern-match against. **Fix:** state the criterion — presumably blocks that commonly carry background images and contain text. - **Unaddressed interaction case.** The note establishes that `background.gradient` and `color.gradient` are separate supports with separate storage, and that themes can set gradients through `theme.json`. It never addresses what happens when a block opts into the new support while its theme still targets `color.gradient`. **Weakness:** this is the obvious edge case created by shipping two parallel systems, and it's exactly what a developer would hit first. **Fix:** state the resolution explicitly, even if the answer is simply "the cascade handles it." - **Migration without timeline or owner.** The consolidation is signposted as intended future work with no timeline, tracking issue, or owner named. **Weakness:** core has a substantial history of parallel API surfaces outliving their stated temporariness, and "eventually" is doing a lot of load-bearing work for developers deciding whether to adopt the new support or wait. **Fix:** link a tracking issue. #### Tone of voice - Precise and economical — roughly 1,200 words of actual content carrying a complete technical argument with no padding, no enthusiasm, and no marketing register. - Explanatory rather than declarative. The note consistently answers "why" before "how," which is unusual in API documentation and is what makes it worth reading rather than skimming. - Reassuring in the right places and about the right things. The backwards-compatibility section is direct and unhedged: nothing breaks, no action required, non-opting blocks unchanged. That's what a developer needs told plainly. - Appropriately modest about scope. The forward-looking paragraph describes groundwork and explicitly disclaims that the migration has happened, resisting the temptation to present a partial step as a completed architecture. - Neutral about the prior implementation. The old approach is described mechanically — it used the shorthand, the shorthand resets properties — with no suggestion that it was a mistake or that anyone erred. That restraint is a small thing and it makes the note easier to trust. ### 🛡️ DARVO Analysis - **Deny:** No DARVO pattern present. This is API documentation with no accusation in play and nothing to deny. The note in fact does the opposite of minimizing — it plainly documents that the previous implementation made a common design goal impossible, without softening or excusing it. - **Attack:** Not present. No person, decision, or prior implementation is disparaged. The `color.gradient` approach is described in purely mechanical terms and explicitly preserved as continuing to work, with no implication that its authors erred. - **Reverse victim/offender:** Not present. There is no accused party, no grievance, and no role reversal. The note's stance toward the existing API is compatible coexistence rather than repudiation. - **Emotional cues and rhetoric:** The register is technical and unemotional throughout, with persuasion carried entirely by causal explanation and code examples. Applying the DARVO frame to an API dev note is a category error — the frame targets defensive responses to accusation, and this is unprompted technical documentation. The honest finding is absence; the note's one real gap is an unargued security assertion, logged under Fallacies. ## 🎯 Conclusion - **Bottom line.** A model dev note. It documents a new `background.gradient` block support, and more valuably it explains *why* the capability was previously impossible: the old support wrote through the CSS `background` shorthand, which resets every background property including `background-image`, so a gradient necessarily erased any image on the same block. The new support writes through the `background-image` longhand, and the style engine emits both as comma-separated values. A years-old limitation traced cleanly to one property choice. - **The transferable lesson.** Shorthands are destructive by design, and that destruction is easy to miss when you're generating CSS programmatically rather than writing it by hand. Anyone building a style engine, a CSS-in-JS layer, or a block support should default to longhand. This is an unusually clean worked example of what it costs to get that wrong. - **The item to look at if you own security review.** `safecss_filter_attr()` has been **loosened** to permit `background-image` values combining a gradient function with a `url()` — it previously stripped them. The change is necessary for the feature and almost certainly narrowly scoped, but the note states it without showing the sanitization reasoning, which is the one place in an otherwise rigorously argued document where an assertion stands in for an argument. Sites accepting block content from untrusted contributors should understand what the filter now permits. - **The accessibility angle nobody names.** The dominant real-world use of gradient-over-image is making text legible over photography — a WCAG 1.4.3 contrast problem. This feature makes the overlay trivially easy to apply and offers no way to verify the result, and effective contrast over a gradient-plus-photo composite is genuinely hard to compute automatically. That difficulty is itself the finding: if tooling can't check it, neither can the person using the control. - **Read it against the trade coverage.** WPBeginner's 7.1 preview, also in this batch, covers this feature in a single line — "background gradients and images work together." Accurate, and it tells you nothing about why they didn't before. Reading the primary dev note alongside the secondary summary is the whole argument for reading dev notes. ## 🔄 Refactor Appendix — background.gradient Block Support in WordPress 7.1 > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) ### [H1] CSS shorthands reset properties you never mentioned > [!quote] ID:rw_pending > The background shorthand resets every background property, including background-image. This meant a gradient set through color.gradient would conflict with, and override, any background image on the same block. **Context & use**: - "Background" section — the root-cause explanation - The whole diagnosis in two sentences, and the most transferable engineering lesson in this batch. A years-old user-facing limitation traced to one property choice. Applies to any programmatic CSS generation — style engines, CSS-in-JS, design token systems. Default to longhand. **Tags**: #xref #share #articleseed **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### [H2] Longhand output is what makes composition possible > [!quote] ID:rw_pending > The key difference is that the new support renders through the background-image longhand property instead of the background shorthand. **Context & use**: - "What changed" section - The fix, and it's elegant — the capability was never blocked architecturally, only by writing to the wrong property. The style engine can then emit gradient and image as comma-separated values in one declaration. **Tags**: #xref **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### [H3] The CSS sanitizer was loosened to permit gradient plus url() > [!quote] ID:rw_pending > In WordPress 7.1, safecss_filter_attr() is updated to allow these combined gradient + url() values, so no additional filter is required. **Context & use**: - "Sanitization" subsection - The one place in an otherwise rigorously argued note where an assertion replaces an argument. `safecss_filter_attr()` is a security boundary constraining CSS in user-supplied content, and this widens what it permits in a property accepting `url()`. Almost certainly fine and narrowly scoped — but read the PR before assuming, especially for sites accepting block content from untrusted contributors. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### [H4] Ship the new support, defer the migration > [!quote] ID:rw_pending > This new support also lays the groundwork for eventually migrating gradient handling from color.gradient to background.gradient across blocks, giving a single, more capable background styling system. That migration is not part of this change. **Context & use**: - "Relationship to color.gradient" - Honest API-evolution signposting: gives direction without overclaiming, and explains the temporary duplication as deliberate rather than accidental. Reusable pattern. The risk is that deferred migrations slip indefinitely — no timeline, tracking issue, or owner is named, and core has history here. **Tags**: #xref #share **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] A convenient abstraction that silently discards state is a bug factory **Claim** (one sentence, Courtney's voice): Any construct that resets values you did not explicitly set will eventually erase something you needed, and the failure will look like a mystery rather than a mistake. **Evidence pointer**: [[#H1]] > [!quote] > The background shorthand resets every background property, including background-image. **Scope & conditions**: Holds wherever a convenience form assigns a whole group of values, resetting unmentioned members to defaults — CSS shorthands, whole-object writes over partial updates, config files that replace rather than merge, ORM saves that null unset columns. The danger scales with how far the writer is from the write: hand-authored CSS makes the reset visible, generated CSS hides it behind a layer. Breaks where the reset is the desired behavior (deliberate state clearing) and where the abstraction requires all members explicitly. **Links**: - [[Principle of least surprise]] — because extends - [[Partial update vs replace]] — because applies-in API design - [[Style engine architecture]] — because evidence-for - [[Leaky abstractions]] — because contrasts on failure mode <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Best worked example I've seen of why programmatic CSS generation should default to longhand. Short post material — "the shorthand that cost WordPress a feature for years" — using #32787 as the case. Generalizes to CSS-in-JS and design token systems. — #fleeting #inbox #articleseed - [F2] Contrast over a gradient-plus-photo composite is genuinely hard to compute — effective background varies per pixel. If automated tooling can't check it, the person using the control can't either. That measurement difficulty is the interesting accessibility problem, and it gets worse as composition features ship. — #fleeting #inbox #articleseed - [F3] `safecss_filter_attr()` loosened without stated reasoning. Read PR #75859 for the sanitization analysis before advising anyone running multi-author or UGC sites. — #fleeting #inbox - [F4] Cross-link: read against the WPBeginner 7.1 preview in the same batch, which covers this in one line ("background gradients and images work together"). Perfect illustration of why primary dev notes beat trade summaries — the summary is accurate and explains nothing. — #fleeting #inbox #xref - [F5] "Ship the capability, defer the migration" as a named API-evolution pattern. Worth collecting core's parallel-support history to see how long these duplications actually last versus stated intent. — #fleeting #inbox #articleseed - [F6] Make network's inline glossary expansions splice definitions mid-sentence and break exactly the causal chains a good dev note constructs. Defines "CSS" in a note about CSS block supports while leaving "style engine" and "serialization" undefined. Accessibility aid aimed at the wrong vocabulary — and a real screen reader sequencing problem. — #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Read Gutenberg PR #75859 for the safecss_filter_attr sanitization reasoning before advising on multi-author sites — WordPress security #things - [ ] Draft the shorthand-vs-longhand post using issue #32787 as the worked example — writing #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/New Block Support in WordPress 7.1 Background Gradient.md|New Block Support in WordPress 7.1: Background Gradient by Make WordPress Core]] ## Highlights - The `background` shorthand resets every background property, including `background-image`. This meant a gradient set through `color.gradient` would conflict with, and override, any background image on the same block. A block could show a gradient or an image, but not both. ([View Highlight](https://read.readwise.io/read/01kyj0b9cmnbryvvx35nmg5b99)) - Note: [H1 / P1] The whole diagnosis in two sentences, and the most transferable engineering lesson in this batch. A years-old user-facing limitation — "why can't I put a gradient over my hero image?" — traced to ONE property choice. CSS shorthands are destructive by design: they reset every member of the group, including ones you never mentioned. GENERAL PRINCIPLE (P1): any construct that resets values you didn't explicitly set will eventually erase something you needed, and the failure looks like a mystery rather than a mistake. Applies to whole-object writes over partial updates, config files that replace rather than merge, ORM saves that null unset columns. The danger scales with distance from the write — hand-authored CSS makes the reset visible; generated CSS hides it behind a layer. Default to longhand in any style engine, CSS-in-JS layer, or design token system. Short post material: "the shorthand that cost WordPress a feature for years," using Gutenberg issue #32787 as the case. - Tags: atom/zettel/z1, atom/literature/h1, css-architecture - **Sanitization.** Previously, `safecss_filter_attr()` stripped a `background-image` value that mixed a gradient function with a `url()`. In WordPress 7.1, `safecss_filter_attr()` is updated to allow these combined `gradient + url()` values, so no additional filter is required. ([View Highlight](https://read.readwise.io/read/01kyj0bm8scgda02evzqh6dbt2)) - Note: [H3] The one place in an otherwise rigorously argued dev note where an assertion replaces an argument. `safecss_filter_attr()` exists specifically as a security boundary constraining what CSS may appear in user-supplied content. This change WIDENS what it permits in a property that accepts `url()` — historically a sensitive construct. The note states the change with no discussion of why the loosening is safely bounded. Almost certainly fine and narrowly scoped. The point is that a security-relevant loosening deserves its reasoning stated in the dev note rather than discovered in the PR. ACTION: read Gutenberg PR #75859 for the sanitization analysis before advising anyone running multi-author publications or membership sites that accept block content from untrusted contributors. Note the contrast with the rest of the note, which explains its reasoning at every single step — that's what makes this gap conspicuous rather than ordinary. - Tags: wordpress-security, atom/literature/h2, action/h1 ## Links - [[3. Resources/Permanent Notes/Zet · Technical constraints shape feature implementation paths]] — evidence-for: CSS shorthand behavior forced separate storage for composable background layers. - [[3. Resources/Permanent Notes/Structured AI Edits Need Platform-Native Validation]] — applies-in: block and theme JSON paths define valid platform-native state.