Twenty Twenty-Two: Dark mode not applied to sub menu in navigation block

[bph]

Default installs with Twenty Twenty Two active + child navigation item have a default background of white font on white background.

The default header is a dark background. The the child navigation text is not visible without first adjusting the navigation block background color.

Screenshot:

This was reported by Courtney Robertson on ​Gutenberg Repo (40908)

[bph]

screenshot

[costdev]

Milestoning for 6.0 for visibility.

[chaion07]

Thanks @bph for reporting this. We reviewed this ticket during a recent bug-scrub session. Based on the feedback received we are updating the ticket with the following changes:

1. Updating the component to 'Bundled Theme'
2. Set focus to 'CSS'

Props to @peterwilsoncc, @bph & @courane01

Cheers!

[costdev]

This ticket was discussed in the bug scrub.

• Increasing the priority/severity to high/major.
• While this doesn't strictly need design assets, adding needs-design to help draw more attention to the ticket to get the best feedback for the visual result.

[poena]

The link color on the group block inside "header dark small" ​template part, - the container around the "header" template part, is overriding the default color.

It is also overriding the navigation block color settings. The text color does not update if I change the text or the submenu & overlay text color options. But the arrow color does.

[poena]

A team of contributors tested this thoroughly during a contributor day at Yoast.

Unfortunately we did not find a solution. We learnt that the problem is in the editor, and not in the theme.
It is an issue with the specificity of the link color in the editor, and we tried different ways both to reduce the specificity, and to increase it.

The contributor day attendees have shared the following information:

1. We cannot increase the priority of the CSS class-structure that inherits the correct color, as stated in the comment in the ​source:

"By adding low specificity, we enable compatibility with link colors set in theme.json,
but still allow them to be overridden by user-set colors."

Important parts of the structure:

.wp-block-navigation .wp-block-navigation-content { color: inherit; }

2. We cannot remove any classes (.editor-styles-wrapper or wp-elements-#) in the class-structure that sets the incorrect color.

Important parts of the structure:

.editor-styles-wrapper .wp-elements-1 a {color: var(—wp—preset—color—background);

The reason we cannot remove the classes:

• .editor-styles-wrapper is auto-generated
• .wp-elements-1 retains the style to a specific part of the website, in this case the header.

3. We cannot decrease the priority of the class-structure that sets the incorrect color (for example using :where).

For both of the previously mentioned classes, it is stated by the developers that the priority is necessary.

"The .editor-styles-wrapper selector is required on elements styles. As it is
added to all other editor styles, not providing it causes reset and global
styles to override element styles because of higher specificity."

​Source

---

-The reason why I did not close and move this issue to the Gutenberg GitHub repository is that there is a potential solution specific for this theme, which is to not use the "header" template part inside the "header dark" template parts.

If the white link color setting is removed from the group block in the header-dark parts, and instead applied directly to the site title, then the white text color would not override the link color in the navigation block.

The reason why we can not add the white color to the site title in the header template part, is that this part is also used on templates with a white background.

These color changes would also need to be carefully tested with the new style variations, and for any backwards compatibility issues.

Pinging @jffng for your thoughts on this issue.

[SergeyBiryukov]

Replying to poena:

A team of contributors tested this thoroughly during a contributor day at Yoast.

Do we have a list of WordPress.org usernames of everyone who tested this today? :) /cc @dennisatyoast

[chaion07]

We reviewed this ticket during another ​recent bug-scrub session. Here's a summary of the discussion:

1. Thanking the Team of contributors from Yoast for testing this.
2. We feel the need to prioritize the Gutenberg side of issues since the most recent one points to the Editor.
3. Requesting @ndiego's attention to this
4. @mikeschroder will leave a comment on the ​Gutenberg issue over Github.

Props to @kafleg, @mikeschroder, @mamaduka, @chaion07 for the discussion

Cheers!

[dennisatyoast]

Replying to SergeyBiryukov:

Replying to poena:

A team of contributors tested this thoroughly during a contributor day at Yoast.

Do we have a list of WordPress.org usernames of everyone who tested this today? :) /cc @dennisatyoast

Thanks for the reminder, @SergeyBiryukov. We tested this together with @daansmeets, @Seraphonano and @WalterLevens.

[peterwilsoncc]

Doesn't look like there's much progress with this so I am bumping it to the 6.0.1 milestone.

[vivekkotadiya]

Hello there,

Please check this. Hope this will help you.

1) ​https://prnt.sc/jToRFjta1baJ
2) ​https://prnt.sc/fxaYu5ABNqBn
3) ​https://prnt.sc/OFldipoec29g
4) ​https://prnt.sc/goRnzuWTRV-w

[SergeyBiryukov]

It looks like this still needs a consensus on the approach from comment:10 and a patch. With 6.0.1 RC1 coming tomorrow, moving to 6.0.2 for now.

[costdev]

#56169 was marked as a duplicate.

[SergeyBiryukov]

Thanks for the patch, @nidhidhandhukiya! Looks like it patches a file in wp-includes/css/dist/block-library/, which should be changed ​upstream in the Gutenberg repository, rather than here in core.

Since there was no further feedback on the approach from comment:10, and 6.0.2 RC1 is coming today, moving this to 6.1 for now.

[poena]

The most resent PR's for this issue are awaiting review:
​Submenu: #44409
​Pagelist, pagelist submenu: #44310

[chaion07]

@bph thank you for reporting this. We reviewed this ticket during a recent bug-scrub session. The related PRs are:

1. ​https://github.com/WordPress/gutenberg/pull/44409
2. ​https://github.com/WordPress/gutenberg/pull/44578 (resolved)
3. ​https://github.com/WordPress/gutenberg/pull/44310

Based on the feedback received from the team we suggest the following:

1. Verifying if this issue still persists
2. Ideally we would want to make sure that the PR didn't resolve things first

Cheers!

Props to @mikeschroder

[bph]

Thanks for the ping @chaion07
I tested this again:
WordPress 6.1 Beta 3 + Gutenberg Nightly of today (includes 14.3 RC).
It seems to resolve the issue. Yes.
Videos Before / After on GitHub issue 40908
Closed as reported and fixed upstream.