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

[poena]

Twenty Nineteen adds extra styling for some blocks, but on the front, the styles use
the class names .entry .entry-content as part of the selector:

.entry .entry-content .wp-block-button .wp-block-button__link:not(.has-background) {
  background-color: #0073aa;
}

So the styles are applied in the post content area, but not applied to blocks placed in the widget area.

The blocks in the widget area on the front does not match what is in the widget admin screen.

[poena]

The button block in the widget area, on the front of the site

[poena]

The button block in the widget area, on the widget admin screen

[ajmcfadyen]

Editor footer widget styles twentynineteen theme

[ajmcfadyen]

Twentynineteen theme footer button widget styles bug

[karmatosed]

Adding the keyword to get testing on this, thank you.

[poena]

@sabernhardt @karmatosed Hi!
In your opinion, what would be the preferred solution for making sure that the theme block styles are applied to blocks in the widget area, not only the post content?

• Apply the styles by adding a selector with .widget-area
• Removing .entry .entry-content selector

Relevant files:
https://core.trac.wordpress.org/browser/branches/6.6/src/wp-content/themes/twentynineteen/sass/blocks/_blocks.scss#L127

https://core.trac.wordpress.org/browser/branches/6.6/src/wp-content/themes/twentynineteen/inc/color-patterns.php#L70

[sabernhardt]

I have not tried to implement any of these, but I can share my preferences for the concepts.

1. If .entry .entry-content can be removed without changing the post content's appearance, that would be my preference. However, those styles may need a higher specificity to override something.
2. If the selectors need higher specificity but one class is enough, I would suggest replacing .entry .entry-content with .site. The color patterns function uses .entry .button (without .entry-content), which suggests that that needed one extra class to override a selector.
3. If it needs two class-level selectors, :root .site might work.
4. Hopefully the stylesheet would not need to copy all of those selectors with a .widget-area variation.

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:

​https://github.com/user-attachments/assets/68640a00-97b0-46ae-9f46-415fc6cb84c4

• After

​https://github.com/user-attachments/assets/9465b39b-b9f3-48d6-bb82-5b58a8038ce0

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.

[SirLouen]

@shubhtoy review code as you are sending a full unnecessary new file

Also, I'm not 100% convinced about that root solution @sabernhardt, can you have a second look when you have a minute?

[sabernhardt]

full unnecessary new file

PR 9019, still in draft status, contains two files: _blocks.scss and style.css. Twenty Nineteen patches need to edit both the SCSS and the compiled stylesheets. Front-end style changes should include a third file, style-rtl.css. @shubhtoy You probably need to run npm run build a ​second time.

not 100% convinced about that root solution

The :root .site selector has a specificity of 0-2-0, same as .entry .entry-content. While I would prefer to reduce the specificity if possible, :root .site theoretically is safer, with less chance of regressions in the content area.

[shubhtoy]

Thanks for the feedback!

You're absolutely right — I missed including style-rtl.css in the patch. I’ll make sure to run npm run build again and include all the necessary compiled files in the next update.

Regarding the :root .site selector — I understand the concern about specificity. My initial thought was to keep it scoped to reduce potential side effects, but I’m open to adjusting it if you think a lower specificity would be safer or more in line with the theme’s conventions. Happy to revisit that part based on your input.

Let me know what you think, and I’ll update the PR accordingly.