# New Block Support in WordPress 7.1 Background Gradient > [!question] Lingering Questions > - `safecss_filter_attr()` was loosened to permit combined gradient + `url()` values, stated without showing the sanitization reasoning — the one place in an otherwise rigorous note where an assertion stands in for an argument. Worth reading Gutenberg PR #75859 directly before advising on multi-author or UGC sites. > - Contrast over a gradient-plus-photo composite is genuinely hard to compute automatically — effective background varies per pixel. If tooling can't check it, the person using the control can't either, and that measurement difficulty gets worse as composition features ship. > [!tip] Article Ideas > - "The shorthand that cost WordPress a feature for years" — the CSS `background` shorthand resetting `background-image` as a worked example for anyone building a style engine, CSS-in-JS layer, or design token system. > - "Ship the capability, defer the migration" as a named API-evolution pattern — worth collecting core's history of parallel-support duplications to see how long they actually last against stated intent. > [!link] Cross Reference > - [[3. Resources/Literature Notes/What's Coming in WordPress 7.1]] — the trade-press summary of this same feature in one line; read together as primary dev note vs. secondary coverage > - [[3. Resources/MOCs/Open Source Governance MOC]] > [!quote] Vocabulary > - **Shorthand vs. longhand (CSS)** — a shorthand property (`background`) implicitly resets every sub-property it covers, including ones not mentioned; a longhand property (`background-image`) sets only itself, which is what makes composition with other values possible ## Bib capsule A Make WordPress Core dev note documenting the new `background.gradient` block support in WordPress 7.1, which lets a block's gradient and background image render together — unlike the existing `color.gradient` support, which could only ever show one or the other. ## Author's thesis A years-old user-facing limitation (gradient overwrites background image, or vice versa) was never an architectural constraint — it was one property choice. Writing gradients through the CSS `background` shorthand silently reset `background-image`; writing them through the `background-image` longhand lets the style engine emit both as comma-separated values in one declaration. ## Key arguments (≤3) 1. **CSS shorthands are destructive by design** — they reset every sub-property they cover, including ones never mentioned, and that destruction is easy to miss when CSS is generated programmatically rather than hand-written. 2. **The fix is architecturally simple once diagnosed**: writing through the longhand property instead of the shorthand removes the conflict entirely, with no new capability required from the style engine. 3. **The note is honest about temporary duplication**: two gradient supports (`color.gradient` and `background.gradient`) now coexist, with migration explicitly deferred rather than claimed as already done. ## Claim atoms ### [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. Where/why: "Background" section, the root-cause explanation. The most transferable engineering lesson in this batch — applies to any programmatic CSS generation, not just this one feature. ### [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. Where/why: "What changed" section. The capability was never blocked architecturally, only by writing to the wrong property. ### [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. Where/why: "Sanitization" subsection. A security boundary widened without shown reasoning — almost certainly fine and narrowly scoped, but worth reading the PR directly for anyone running multi-author sites. ### [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. Where/why: "Relationship to color.gradient." Honest API-evolution signposting — no timeline, tracking issue, or owner named, which is the risk in any deferred migration. ## Permanent candidates - **[P1] A convenient abstraction that silently discards state is a bug factory** — promoted, see [[3. Resources/Permanent Notes/A Convenient Abstraction That Silently Discards State Is a Bug Factory]] ## Processing checklist - [x] Port claim atoms and permanent candidates from the existing deep-read - [x] Connect into [[3. Resources/MOCs/Open Source Governance MOC]] - [ ] Read Gutenberg PR #75859 for the safecss_filter_attr sanitization reasoning before advising on multi-author or UGC sites ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — a core dev-note case study in how WordPress ships a capability while explicitly deferring the cleanup migration - [[3. Resources/Readwise/Articles/New Block Support in WordPress 7.1 Background Gradient]] — source document