Improve color indicators in style previews

[richtabor]

Related to this comment by @ramonjd, I propose we adapt how the highlightedColors are chosen for style variations and associated UI. This way it's a clearer visual of the actual colors applied from the variation.

I'm thinking the first indicator should be the text color, with the second using the button color. If there's no button color, it would fallback to the text color, which is fine, as that variation may be more minimal. There would always be two indicators, maintaining consistency in the UI, reducing confusion.

This would also ensure that the color indicators have appropriate contrast values, as they are styled with the same values that are expected to have a high contrast value against the variation's background color.

These indicator colors should be the same for full theme style variations as well, not just instances of these 'mini' selectors.

[mtias]

Shouldn't button color fallback to link color instead of text?

[bgardner]

Not sure how I feel about this suggestion TBH. I realize I'm an exception_not_the_rule with my choice of design. My Powder theme includes 22 style variations, but I still set the Buttons (block or element) background to Contrast (not any of the colors) and the same is true of Links. The colors in each palette are there for convenience sake. If this goes through, all 22 variations will essentially show black and black. Not ideal. A way around this is to update the background of Buttons (block or element) from Contrast to Primary, which would look better in the Site Editor (and WP.org theme page), but also result in unexpected/breaking changes for anyone using the theme.

[richtabor]

Shouldn't button color fallback to link color instead of text?

Yea, that makes sense to me.

[richtabor]

@bgardner how else would you suggest? Are the colors in the variations used in the variations, or just setting the palette?

[spencerfinnell]

Echoing my thoughts from a couple of years ago I still believe it would be nice for these "previews" to be defined by the theme author.

block.json supports example, what about something similar in theme.json?

[bgardner]

I like @spencerfinnell's suggestion. (If anything as primary method, fallbacks as described above would be ok.)

This would allow me to show Contrast (Text) and the Primary (main accent) colors in each preview, which would be ideal in my case.

[richtabor]

I still believe it would be nice for these "previews" to be defined by the theme author.

I don't think that's a bad idea, although I do think a better fallback for when themes don't would still be beneficial.

[richtabor]

Here's an example from TT4, using the proposed method here.

I observe:

• The results are less random, as the colors are consistently pulled from background, text, and button background (with link color as a fallback).
• The previews are have appropriate contrast out-of-the-box, as text and buttons contrast with the background of the site/preview.

Current	Proposed

[bgardner]

@richtabor Are we still considering allowing theme authors to specify in theme.json?

The results are less random, as the colors are consistently pulled from background, text, and button background (with link color as a fallback).

Because with Powder, whether it be button background or link color, all of my variations would essentially show black/black on white.

[spencerfinnell]

Possibly semi-related: #49661

[spencerfinnell]

Also semi-related if a new entry point for previews is added to theme.json (which seems very logical to me): #57286

[richtabor]

@richtabor Are we still considering allowing theme authors to specify in theme.json?

Yes, I think it's worth considering; perhaps like block.json's example object.

@spencerfinnell @bgardner What do you think that would look like ideally in theme.json?

[bgardner]

@richtabor Could be as simple as:

{
	"settings": {
		"preview": [
			{
				"colors": [ "#f5f5f5", "#0a0a0a", "#6d28d9" ]
			}
		]
	}
}

[richtabor]

@bgardner mind opening an issue up about that specifically? I don't want it to get lost.

[richtabor]

@richtabor Could be as simple as:

Maybe just the highlight colors (the two circles), allowing the background to maintain as the background of the preview.

I wonder if example works well, as it's closer to block.json, and maybe even top-level.

[justintadlock]

I'd be good with the proposed system as a default/fallback. It's definitely an improvement over what we have today.

I'm in favor of the preview colors being customizable even more.