Make WordPress Core

Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#55697 closed defect (bug) (reported-upstream)

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

Reported by: bph's profile bph Owned by:
Milestone: 6.1 Priority: high
Severity: major Version: 6.0
Component: Bundled Theme Keywords: needs-design
Focuses: css Cc:

Description

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:screenshot

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

Attachments (2)

tt2-navigation.png (105.7 KB) - added by bph 3 years ago.
screenshot
55696.diff (86.1 KB) - added by nidhidhandhukiya 2 years ago.

Download all attachments as: .zip

Change History (29)

@bph
3 years ago

screenshot

#1 @costdev
3 years ago

  • Milestone changed from Awaiting Review to 6.0

Milestoning for 6.0 for visibility.

This ticket was mentioned in Slack in #core by chaion07. View the logs.


3 years ago

#3 @chaion07
3 years ago

  • Component changed from Themes to Bundled Theme
  • Focuses css added

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!

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


3 years ago

This ticket was mentioned in Slack in #core by costdev. View the logs.


3 years ago

#6 @costdev
3 years ago

  • Keywords needs-design added
  • Priority changed from normal to high
  • Severity changed from normal to major

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.
Last edited 2 years ago by costdev (previous) (diff)

#7 @poena
3 years ago

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.

#8 @poena
3 years ago

  • Owner set to poena
  • Status changed from new to assigned

#9 @poena
3 years ago

  • Owner poena deleted

#10 follow-up: @poena
3 years ago

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; }
  1. 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.
  1. 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.

One major downside to not re-using the header template part is that users would need to update their header content, like the navigation block, in more than one place.

Pinging @jffng for your thoughts on this issue.

Last edited 3 years ago by poena (previous) (diff)

#11 in reply to: ↑ 10 ; follow-up: @SergeyBiryukov
3 years ago

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

This ticket was mentioned in Slack in #core by chaion07. View the logs.


3 years ago

#13 @chaion07
3 years ago

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!

#14 in reply to: ↑ 11 @dennisatyoast
3 years ago

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.

This ticket was mentioned in Slack in #core-editor by ndiego. View the logs.


3 years ago

#16 @peterwilsoncc
3 years ago

  • Milestone changed from 6.0 to 6.0.1

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

#18 @SergeyBiryukov
2 years ago

  • Milestone changed from 6.0.1 to 6.0.2

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.

#19 @costdev
2 years ago

#56169 was marked as a duplicate.

#20 @SergeyBiryukov
2 years ago

  • Milestone changed from 6.0.2 to 6.1

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.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


2 years ago

#22 @poena
2 years ago

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

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


2 years ago

This ticket was mentioned in Slack in #core by chaion07. View the logs.


2 years ago

#25 @chaion07
2 years ago

@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

#26 @bph
2 years ago

  • Resolution set to reported-upstream
  • Status changed from assigned to closed

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.

Closed as reported and fixed upstream.

Version 0, edited 2 years ago by bph (next)

#27 @desrosj
2 years ago

  • Summary changed from Twenty-Twenty-Two: Dark mode not applied to sub menu in navigation block to Twenty Twenty-Two: Dark mode not applied to sub menu in navigation block
Note: See TracTickets for help on using tickets.