Blocks text placeholder may have insufficient color contrast depending on the active theme

[afercia]

Description

Some blocks display a placeholder text.

• For blocks that use the RichText component, it's a CSS generated content.
• For blocks that use an input element, it's the HTML placeholder attribute.

In all cases, the placeholder text must meet the color contrast ratio requirement of 4.5:1. It is part of the user interface so that the editor must make sure it is readable for everyone.

Turns out the color of the text placeholder may inherit from the active theme.
For the RichText, the editor CSS sets a CSS opacity: .62; regardless.

Setting that opacity doesn't seem to be ideal. When the active theme uses a light color, the opacity set by the editor may bring the contrast ratio below the required threshold. This is the case with Twenty Twenty-Four, for example.

Iin the screenshot below, I'm comparing some block text placeholder in the editor. On the left, with Twenty Twenty-Three active and on the right with Twenty Twenty-Four active.

Observe the color of some of the placeholders actually changes depending on the theme and it has insufficient contrast.

Step-by-step reproduction instructions

• Create a post.
• Add some blocks that have text placeholders, for example:
  • Image (for the caption placeholder)
  • Gallery (for the gallery caption placeholder)
  • Site tagline
  • Site title
  • More
  • Read more
• Empty any default content from the inputs, to reveal the placeholder text.
• Observe all the placehholder text with different themes active e.g. with Twenty Twenty-Three and with Twenty Twenty-Four.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[afercia]

Noting that some bocks have some specific handling of the opacity for the placeholder text, which is less than ideal. See for example #42519 / #35928

[afercia]

Note: there is a scss mixin that styles the placeholder attribute but it is only used for some inputs of the editor interface. It's not used for the blocks placeholder.

[afercia]

Screenshot with a dark theme (actually a Twenty Twenty-Four style variant):

[afercia]

While working on this, I noticed the CSS class is-dark-theme is not applied correctly to the post editor. It works as expected in the site editor. That's a blocker for this issue. I will create a separate issue and PR.

[afercia]

After some research in the project history, I found some related argumentations in #33058, specifically:

we do need the placeholder colors customized for text inputs in the canvas

I don't think the text placeholder within the editor canvas should match the colors set by the theme or customized by the user. The text placeholders aren't part of the site preview. Instead, they are part of the user interface, whether they are placeholder of input elements or the placeholder of the RichText component.

As such, text placeholders in the canvas must always be readable, whatever the background color is. Their color must be set by the editor. Of course, this should not affect text placeholders in other parts of the editor UI, e.g. sidebars, panels, popovers, etc.

One special case that exposes a similar issue is the Cover block. The block detects the color of the image overlay or background color and dynamically changes the text placeholder and also the default cover text color. But, when users set a custom text color, it is set also on the text placeholder. This shouldn't happen because the text placeholder may become unreadable. Instead, an editable input placeholder should always be visible. Animated GIF to illustrate:

[afercia]

See related past considerations regarding the missing is-dark-theme CSS class on #64548 / #64549

[afercia]

Note to myself:
The opacity for the native placeholder attribute e.g. -webkit-input-placeholder and the like was originally introduced in #6406 and then went through various refactorings e.g. in #9562. Many things have changed since then and now the placeholder mixin seems being used only for the UI controls, not for placeholder attributes in the blocks.
There's separate rulesets for the editor in 'Code editor' mode.

[himanshupathak95]

Hey @afercia,

I have a PR - #69312 that removes the opacity: 1 CSS property from ::-moz-placeholder selectors throughout as your issue #69311 mentions.

I see your changes here in #69333 also partly remove the opacity: 1 CSS property at places and create a mixin, which might conflict with #69312.

So I think we should either ship #69312 first and then proceed with your changes or incorporate all the changes in any one of the PR since the changes are almost similar. This way I think we can avoid conflicts and streamline the approach better.

What do you think?

[afercia]

@himanshupathak95 I would say to merge your #69312 first as it's simpleer and self-contained. I'll then rebase my PR, no rpoblems.

[afercia]

One more finding is about the opacity for the caption placeholder:

gutenberg/packages/block-editor/src/components/rich-text/content.scss

Lines 1 to 23 in 0d5c310

	.rich-text {
	[data-rich-text-placeholder] {
	pointer-events: none;
	}
	[data-rich-text-placeholder]::after {
	content: attr(data-rich-text-placeholder);
	// Use opacity to work in various editor styles.
	// We don't specify the color here, because blocks or editor styles might provide their own.
	opacity: 0.62;
	}
	&:focus {
	// Removes outline added by the browser.
	outline: none;
	}
	}
	// Captions may have lighter (gray) text, or be shown on a range of different background luminosites.
	// To ensure legibility, we increase the default placeholder opacity to ensure contrast.
	figcaption.block-editor-rich-text__editable [data-rich-text-placeholder]::before {
	opacity: 0.8;
	}

It uses this selector:
figcaption.block-editor-rich-text__editable [data-rich-text-placeholder]::before

to increase the opacity for the captions. However, I'm not sure that has ever worked because the placeholder text uses ::after instead of ::before. Introduced in #16733. That PR mentions that at some point the placeholders were first implemented with ::before so it could be something that was missed at some point.

Also, I would argue that the reasoning that the caption placeholder needed some higher opacity to be better readable, that is valid for all placeholders of all blocks so that at the very least I'd propose to increase the opacity value for the default placeholder to 0.8 or maybe even a little more.