WordPress.org

Make WordPress Core

Opened 3 months ago

Last modified 3 months ago

#53525 new enhancement

On WP 5.8-beta4-51244 inside toggle block inserter default search text is not visible when in dark mode

Reported by: alanjacobmathew Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Editor Keywords: needs-testing
Focuses: ui Cc:

Description (last modified by SergeyBiryukov)

v: WP 5.8-beta4-51244
theme: Twenty Twenty One

When the user has dark mode switched ON, inside the block inserter, default 'search' text is not clearly visible as the text colour is in white. This is a low priority problem as there is a search icon next to it and the user clearly understands that it is a search functionality.

Steps to reproduce
1: Enable dark mode ON
2: open a post and click on block inserter
3 Click somewhere outside the search box

Expected Result: The default text in search bar to be dark when 'dark mode is ON'

Attachments (3)

search button 5.8.png (5.5 KB) - added by alanjacobmathew 3 months ago.
Default text in search button- Enhancement
53525.diff (93.6 KB) - added by sumaiyasiddika 3 months ago.
Created patch
darkmode-inserter.png (57.5 KB) - added by poena 3 months ago.

Download all attachments as: .zip

Change History (15)

@alanjacobmathew
3 months ago

Default text in search button- Enhancement

#1 @alanjacobmathew
3 months ago

  • Summary changed from On WP 5.8-beta4-51244 inside toggle block inserter search text is not visible when in dark mode to On WP 5.8-beta4-51244 inside toggle block inserter default search text is not visible when in dark mode

#2 @SergeyBiryukov
3 months ago

  • Description modified (diff)
  • Milestone changed from Awaiting Review to 5.8

@sumaiyasiddika
3 months ago

Created patch

#3 @sumaiyasiddika
3 months ago

  • Keywords has-patch needs-testing added

#4 @Clorith
3 months ago

  • Keywords has-patch removed

Thank you for the patch @sumaiyasiddika, this does appear to be an issue caused by the darkmode feature of the Twenty Twenty One theme though, so it should probably be solved in the theme.

(As a side-note, the file you modified is a built style file, meant for a final release, and is not the one that should be edited, instead the source files should be modified, in the case of your patch above, this would be a file that is part of the Gutenberg repository on GitHub)

#5 @poena
3 months ago

Hi
I have not been able to reproduce this on 5.8-beta4-51247 Windows 10, Chrome Version 91.0.4472.114,
can you provide any more details?

I tested with the default body background color, and a custom almost white background color (not from the palette), with dark mode on.

#6 @alanjacobmathew
3 months ago

Hi @poena ,

Could you try without typing any text in the search box and click somewhere outside the searchbox(probably the scroller). The default placeholder text 'search' is not visible clearly as it is in white shade.

#7 @poena
3 months ago

Thank you, yes I can see it now.
It also happens when dark mode is turned off and the body background color is any dark color from the palette or color picker.

Because of that, I tested with two other themes. I choose Twenty Twenty, which has support for dark editor styles, and confirmed that the same problem happened with that theme.

The second theme was a copy https://github.com/Automattic/_s because it is basically blank.
In functions.php, I added

add_theme_support( 'editor-styles' );
add_theme_support( 'dark-editor-style' );
add_editor_style( 'editor-style-dark.css' );

I created a blank css file called editor-style-dark.css.
The blank file did nothing, the color in the search field was correct.
I added a body background to the CSS file:

body {
	background: #333;
}

This changed the text color of the search field.
Note that this is all the CSS in the file. There is no text color.

The conclusion is that this is not a theme issue, but an issue with the editor when
add_theme_support( 'dark-editor-style' ); is used.

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

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


3 months ago

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


3 months ago

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


3 months ago

#11 @JeffPaul
3 months ago

  • Milestone changed from 5.8 to Future Release

After some research on this in #core (thanks @Clorith for the assist there, see Slack archive link above), I'm going to punt this to Future Release and if research determines a sensible approach it can get puled back into a 5.8.1 or 5.9 milestone at that time.

#12 @Joen
3 months ago

Thank you for the report. The particular property in question, add_theme_support( 'dark-editor-style' ); has a varied history, so just for historical purposes and for anyone coming back to this ticket in the future, here's a bit of background:

  • Its purpose is to allow the block editor to provide contrastful UI against theme backgrounds. For instance if a theme has a dark blue background, the blue focus style would not be legible, so the theme could declare that it was a "dark theme" and the focus style would be white instead.
  • What the property did was output a CSS class, is-dark-theme, on the body tag, so that the UI of the block editor would be able to invert itself and ensure contrast.
  • The actual property has been deprecated and is now fully automated; the block editor detects if the theme has a dark background and applies the class.
  • Don't confuse the property with the similarly named "dark mode" provided by operating systems, it has nothing to do with that.

Regarding the specific bug, thank you for the steps to reproduce. I've tracked it down to a placeholder color property being applied to the block editor when it shouldn't have been. The fix and furthe details can be found in this PR: https://github.com/WordPress/gutenberg/pull/33058

I look forward to one day in the future when we can bring actual dark mode to WordPress and the block editor using @media (prefers-color-scheme: dark)! But for the time being, this was just a copy paste bug!

Note: See TracTickets for help on using tickets.