Skip to content

Twenty Nineteen: Theme block styles are not applied to blocks in the widget area#9019

Open
shubhtoy wants to merge 3 commits into
WordPress:trunkfrom
shubhtoy:bundled/twenty-nineteen-footer-button-css-60408
Open

Twenty Nineteen: Theme block styles are not applied to blocks in the widget area#9019
shubhtoy wants to merge 3 commits into
WordPress:trunkfrom
shubhtoy:bundled/twenty-nineteen-footer-button-css-60408

Conversation

@shubhtoy

Copy link
Copy Markdown

This PR addresses a CSS specificity issue in the Twenty Nineteen theme where Gutenberg block styles, particularly button styles, were not being applied consistently across different areas of the site due to insufficient selector specificity.

Problem

The original CSS selectors used .entry .entry-content as the base, which meant:

  1. Block styles only applied in post/page content areas - Blocks in widget areas (like footer widgets) didn't receive the theme's custom styling
  2. Inconsistent visual experience - The same button block would look different in the content area vs. widget areas
  3. Backend/frontend mismatch - Widget editor showed one appearance while frontend showed another

Example of the issue:

/* Before - only applies in post content */
.entry .entry-content .wp-block-button .wp-block-button__link:not(.has-background) {
    background-color: #0073aa;
}

/* After - applies site-wide with higher specificity */
:root .site .wp-block-button .wp-block-button__link:not(.has-background) {
    background-color: #0073aa;
}

Changes Made

  • Increased CSS specificity by changing selectors from .entry .entry-content to :root .site
  • Applied to all Gutenberg blocks including:
  • Button blocks (primary focus of this fix)
  • Pullquote, Quote, Image, Cover blocks
  • Gallery, Separator, Table, File, Code blocks
  • Column, Group, Latest Comments blocks
  • Font size and color utility classes
  • Maintains visual consistency across post content, widget areas, and other contexts
  • Ensures backend-frontend parity for block appearance in widgets

Steps to Reproduce the Original Issue

  1. Go to Appearance > Widgets
  2. Add a Button block to a widget area (e.g., Footer 1)
  3. Configure the button with default styling (no custom background color)
  4. Backend: Button appears with Twenty Nineteen's blue theme color (#0073aa)
  5. Frontend: Button appears with browser default styling (not blue)
  6. After this fix: Button appears consistently blue in both backend and frontend

Technical Details

The :root .site selector provides higher specificity than the original .entry .entry-content while still being scoped to the site container. This ensures the styles apply everywhere blocks can appear while maintaining the theme's design integrity.

Specificity comparison:

  • Before: .entry .entry-content (0,0,2,0)
  • After: :root .site (0,0,1,1) with :root pseudo-class providing higher effective specificity

Artificats (Screen Recordings)

  • Before:
Screen.Recording.2025-06-19.at.5.16.29.PM.mov
  • After
Screen.Recording.2025-06-19.at.5.18.28.PM.mov

Trac ticket: #60408


This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

@github-actions

Copy link
Copy Markdown

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

  • The Plugin and Theme Directories cannot be accessed within Playground.
  • All changes will be lost when closing a tab with a Playground instance.
  • All changes will be lost when refreshing the page.
  • A fresh instance is created each time the link below is clicked.
  • Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
    it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

@shubhtoy shubhtoy marked this pull request as ready for review June 20, 2025 09:12
@github-actions

Copy link
Copy Markdown

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props shubhtoy.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant