Text Shadow Support in Global Styles  🔗 **Source:** [Text Shadow Support in Global Styles](https://make.wordpress.org/core/2026/07/23/text-shadow-support-in-global-styles/) > [!note]+ Document Notes > tags: [wordpress-7-1, global-styles, theme-json, typography, block-themes] > author: WordPress Core contributors > source: Make WordPress Core > reference: https://make.wordpress.org/core/2026/07/23/text-shadow-support-in-global-styles/ > date created: > > # 🏷️ Title: Text Shadow Support in Global Styles > <!-- 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--text-shadow-support-in-global-styles) - [🧰 Template Library](#-template-library) ### 🔗 References - [Text Shadow Support in Global Styles](https://make.wordpress.org/core/2026/07/23/text-shadow-support-in-global-styles/) - [Typography feature request](https://github.com/WordPress/gutenberg/issues/47904) - [Planned text-shadow controls and presets](https://github.com/WordPress/gutenberg/pull/79584) ## 📝 Summary - WordPress 7.1 adds `textShadow` under `styles.typography` in `theme.json`. - Theme authors can set text shadows globally, per block, and on elements and states such as link hover. - The value maps directly to CSS `text-shadow`, including comma-separated multiple shadows. - WordPress 7.1 ships only the data-model and rendering slice. Inspector controls, Global Styles UI, presets, and block support are planned for the next release. - The main stakeholders are theme authors, block developers, designers, accessibility reviewers, and site owners. The main risk is unreadable or distracting text when shadows are applied without contrast and readability tests. - Bottom line: themes can start declaring text shadows now, but should treat them as progressive enhancement and test every state. ## 📖 Main Content - **Background:** Before 7.1, theme authors needed custom CSS because the block style system did not understand text shadows. - **Smallest useful slice:** Core adds the declaration path before the control design and preset system are settled. - **Property shape:** `styles.typography.textShadow` accepts any valid CSS `text-shadow` value. The property works at global, block, and element levels. - **Cascade:** Block-level values override global values like other typography styles. Element states can reset shadows, including `none` on link hover. - **Editor behavior:** Empty rich-text placeholders suppress the global shadow so the prompt remains readable. Actual content keeps the configured shadow in the editor and front end. - **Deferred work:** The next release is expected to add controls, preset storage and custom properties, and `supports.typography.textShadow` for Paragraph and Heading. - **Compatibility:** The change is additive. Themes that do not set the property behave as before. ## 🗒️ Notes - The feature enters through `theme.json`, not the interface. That makes it available to developers before it becomes discoverable to ordinary users. - The direct CSS value offers flexibility but lacks preset governance in this release. - Multiple shadows can create effects that are difficult to review or keep consistent across themes. - The placeholder reset shows that editor affordances need protection from content styles. - Element-state support matters because a shadow that works on default text may fail on hover, focus, or changed backgrounds. - The staged release isolates data storage and rendering from control design, which lowers decision coupling but creates a temporary developer-only phase. ## 📚 References - [Make WordPress Core dev note](https://make.wordpress.org/core/2026/07/23/text-shadow-support-in-global-styles/) - [Gutenberg issue 47904](https://github.com/WordPress/gutenberg/issues/47904) - [Gutenberg PR 79584](https://github.com/WordPress/gutenberg/pull/79584) - [MDN: text-shadow](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow) ## 🗣️ Paraphrase - WordPress now recognizes text shadows as structured typography data instead of leaving them in custom stylesheets. - Themes can set the property at the same levels where they set other typography values. - Core deliberately ships a narrow first step: developers get configuration and rendering now, while user controls and presets wait. - Theme authors gain a standard path, but they remain responsible for restraint, contrast, state testing, and fallback behavior. ## 📰 Newsletter WordPress 7.1 brings `text-shadow` into `theme.json`, which means block themes can finally set shadows globally, by block, or by element without a custom stylesheet. This is the developer-first slice: no inspector control, no preset browser, and no per-block UI yet. Enjoy the new typography knob, but remember that three glowing shadows do not automatically make a heading more readable. [Read the dev note](https://make.wordpress.org/core/2026/07/23/text-shadow-support-in-global-styles/). ## ✅ Action Items #### DevRel - Publish restrained examples that include readability tests. - Explain the 7.1 scope and the next-release roadmap. - Run a theme-author lab covering global, block, and element states. - Track adoption and accessibility defects separately. #### OSPO - Record the new schema field in supported platform baselines. - Review copied shadow recipes for provenance and license. - Encourage upstream accessibility guidance and test fixtures. - Track theme.json schema changes across maintained products. #### Community - Maintainers: add tested examples and state coverage. - Contributors: report editor/front-end mismatches with minimal theme.json files. - Sponsors: support accessibility and visual regression work. - Ecosystem: share examples that favor legibility over decoration. #### WordPress - Core: document schema, cascade, validation, and release boundaries. - Core Performance: measure CSS output and style-engine cost for multiple shadows. - Core AI: stop generated designs from adding unreadable decorative shadows by default. - Core Program Team: track the dependency chain from schema to presets, controls, docs, and accessibility review. - Mobile: confirm rendering and editing parity or document limits. - Playground: host a theme.json typography lab. - Community: include the feature in block-theme developer sessions. - Training: teach progressive enhancement and state testing. - Marketing: present it as a developer capability in 7.1, not a complete user control. - Support: document how to remove or override an unreadable shadow. - Design: define sensible control ranges and preset previews. - Documentation: add schema examples and the list of deferred features. - Photos: no direct action. - TV: caption a short Global Styles demo. - Polyglots: test controls and labels once the UI arrives. - Accessibility: test contrast, blur, cognitive load, hover, focus, zoom, and forced-colors behavior. - Meta: avoid decorative shadows on high-density administrative text. - CLI: expose schema validation and theme.json linting examples. - Hosting: include 7.1 theme.json validation in staging checks. - Tide: consider checks for extreme or unreadable shadow values only if false positives stay low. - Openverse: test captions and attribution text under inherited global shadows. - Themes: review global inheritance and reset sensitive components. - Plugins: honor theme.json output without duplicating conflicting CSS. #### The WPOCC - Fund a small accessible typography recipe library. - Support shared theme.json test fixtures across theme projects. ### FAIR - Keep text-shadow settings in portable theme metadata. - Document schema versions and fallback behavior. - Publish accessibility expectations for distributed theme packages. ## 🧪 Hypotheses - Data-model-first shipping produces earlier theme adoption than waiting for the full interface. - Theme authors use global shadows more often than element-state shadows. - Direct free-form values create more visual inconsistency than preset-based values. - Placeholder resets prevent a measurable class of editor-readability defects. - Accessibility guidance published before the UI reduces harmful presets in the next release. ### 📊 Methodology - Sample block themes before and after 7.1 for `textShadow` use and placement. - Run automated and human readability checks across light, dark, high-contrast, and forced-colors modes. - Compare direct values with a controlled preset system for consistency and task completion. - Measure editor/front-end parity and collect defect reports by cascade level. ### ❓ Questions - How will presets balance expressive range with readable defaults? - Will the interface expose blur, offsets, color, and multiple layers separately? - How should accessibility warnings work without blocking legitimate high-contrast shadows? - Should forced-colors mode ignore or reset theme-defined shadows? - Which blocks need explicit resets for placeholders and controls? ### 🔮 Future Research - Test text shadows with dyslexia, low vision, migraine, and cognitive-accessibility participants. - Compare text-shadow legibility across variable fonts, font weights, and responsive sizes. - Study whether preset previews make multiple-shadow effects understandable before selection. - Audit theme inheritance to identify components that should not receive a global shadow. ### 💡 Implications - **Practice:** theme authors can move decorative typography into structured configuration. - **Policy:** a complete feature needs accessible defaults and clear preview behavior. - **Security:** no direct security effect; schema validation should still reject malformed data safely. - **Education:** examples should teach cascade, state coverage, and readability. - **Funding:** shared accessibility research can guide Core and theme authors before controls ship. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid grade 10–12 because of CSS and theme.json terminology. #### 👀 Visual learners - Present: a full theme.json example. - Improve: add rendered before-and-after samples for every cascade level. #### 🔊 Aural learners - Present: not applicable; no audio in the captured source. - Improve: add a short narrated demonstration. #### 🗣️ Verbal learners - Present: clear scope and definitions. - Improve: explain shadow components in plain language. #### 🧩 Kinesthetic learners - Present: copyable configuration. - Improve: provide a Playground lab with editable values. #### 🧠 Logical learners - Present: clear cascade and phased roadmap. - Improve: add a precedence table and schema map. #### 🧑‍🤝‍🧑 Social learners - Present: issue and pull-request links. - Improve: add a moderated design-review exercise. #### 🧘‍♀️ Solitary learners - Present: self-contained examples. - Improve: add a checklist for states and readability. #### 🌿 Naturalistic learners - Present: not applicable; no environmental theme. - Improve: frame the feature lifecycle from raw value to governed preset. ### 📊 Accessibility Assessment #### Screen reader semantics - Text shadows do not change semantics, but examples still need clear headings and code labels. #### Keyboard navigation - The 7.1 feature has no control UI. Future controls need complete keyboard operation and visible focus. #### Contrast and readability - Shadows can reduce edge clarity, create false contrast, or obscure small text. Test actual foreground/background combinations. #### Text resizing and reflow - Check shadows at 200% zoom and responsive font sizes for clipping and visual noise. #### Media and captions - Not applicable to the current article. #### Forms and interactions - Future controls need labels, errors, reset actions, and target sizes meeting WCAG 2.2. #### Standards reference - Check WCAG 2.2 AA criteria 1.4.3, 1.4.6 as enhanced guidance, 1.4.10, 1.4.11, 2.4.7, and 2.5.8. ### 🌍 DEIB Assessment #### Cultural breadth - Decorative typography norms vary; preset research should include more than one design tradition. #### Inclusive language - The source uses neutral technical language. #### Neurodiversity support - Clear sections help scanning; animated or intense glow examples should be avoided. #### Representation - No user research or participant voices appear. #### Psychological safety - Accessibility warnings should explain risks without shaming designers. ### ✅ Logical Validity #### Strong reasoning - The post clearly separates current capability from planned work. - It explains why Core chose a narrow slice: unresolved control and preset decisions should not block the useful configuration path. - It states compatibility limits and no-action behavior for existing themes. #### Fallacies - No material fallacy appears. The phrase “smallest useful piece” is a product judgment; supporting it with adoption or implementation-cost evidence would make the claim testable. #### Tone of voice - Candid, incremental, and technical. The source marks what is absent as clearly as what shipped. ### 🛡️ DARVO Analysis - Deny: not applicable. - Attack: not applicable. - Reverse victim/offender: not applicable. - The source contains no accusation, defensive conflict, or blame-shifting. ## 🎯 Conclusion WordPress 7.1 adds a standard text-shadow path to the Global Styles data model while leaving controls and presets for the next release. Theme authors can use it now at global, block, and element levels. The responsible next step is to test cascade, readability, interaction states, zoom, and editor parity before enabling shadows broadly. ## 🔄 Refactor Appendix — Text Shadow Support in Global Styles ### 📚 Literature Atoms ### [H1] Text shadows enter theme.json > [!quote] ID:rw_1036798924 > WordPress 7.1 introduces the ability to define a text-shadow value in Global Styles through theme.json. **Context & use**: - Opening feature statement. - Use when tracking which visual styles move from custom CSS into structured theme data. **Tags**: #xref **Highlight**: [view highlight](readwise://open/1036798924) <!-- atomicity: 1 idea ✓ --> ### [H2] Core ships the smallest useful slice > [!quote] ID:rw_1036798925 > This release adds the smallest useful piece: the ability to declare a text-shadow value directly in theme.json. **Context & use**: - Background and release-scope rationale. - Use as an example of reducing decision coupling in staged feature work. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://open/1036798925) <!-- atomicity: 1 idea ✓ --> ### [H3] Configuration arrives before controls > [!quote] ID:rw_1036798926 > There is no block inspector control and no Global Styles interface for this in this release. **Context & use**: - Current-scope limitation. - Use when distinguishing developer availability from user discoverability. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://open/1036798926) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates #### [P1] Data-model-first releases reduce decision coupling **Claim**: Shipping a narrow data path lets useful work proceed before interface design settles. **Evidence pointer**: [[#H2]] **Scope & conditions**: Applies when the data contract is stable enough to support later controls; breaks when early storage choices constrain unresolved user needs. **Links**: - [[Progressive feature delivery]] — because extends staged releases. - [[Developer availability versus user discoverability]] — because contrasts configuration with interface access. - [[Global Styles]] — because applies-in theme typography. <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Compare adoption during the developer-only phase with adoption after presets and controls arrive — feature research #xref. ### → Things 3 - [ ] Test global, block, link-hover, zoom, and forced-colors text shadows in Playground — WordPress 7.1 #things <!-- deep-read:sections end --> ## Highlights - WordPress 7.1 introduces the ability to define a text-shadow value in Global Styles through theme.json. Themes can now set a text shadow globally, on specific blocks, and on elements such as links, without a plugin or custom stylesheet. ([View Highlight](https://make.wordpress.org/core/2026/07/23/text-shadow-support-in-global-styles/#theme-json)) - Note: H1 — Text shadows enter the Global Styles data model. - To make progress without waiting on those decisions, this release adds the smallest useful piece: the ability to declare a text-shadow value directly in theme.json. ([View Highlight](https://make.wordpress.org/core/2026/07/23/text-shadow-support-in-global-styles/#smallest-piece)) - Note: H2 — The feature ships in a narrow data-model-first slice. - There is no block inspector control and no Global Styles interface for this in this release. The value is set in theme.json only. ([View Highlight](https://make.wordpress.org/core/2026/07/23/text-shadow-support-in-global-styles/#no-ui)) - Note: H3 — WordPress 7.1 exposes storage and rendering before editor controls.