Use lighter red shades for error messages

[pat-s]

The current one has low contrast in the dark theme and is somewhat hard to look at.

The new red color represents the "500" shaded in the palette. Other colors from the generic red palette have been adjusted in the linked palette.

Old	New

[xoxys]

IMO this is way too "aggressive" for the eyes in dark mode and I would prefer the current desaturated variant.

[pat-s]

IMO this is way too "aggressive" for the eyes in dark mode and I would prefer the current desaturated variant.

Does this apply to both shades or only the button background? Note that the icon one is darker.

[xoxys]

There are two different red tones used for the icon and the button?

[pat-s]

Two classes (there are many redundant ones with the same color but this is a different topic) but only one tone: #c93c37. (I tried using different ones in a previous state but the current one only uses one color).

It would be great if there could be additional opinions as it is hard to move on in such UI discussions if there's always a 1:1.

(just as a side note: I have found the red color being way too dark since the theme existed, this is not a recent discovery. I have also compared the WP color with other common red colors in dark themes (GH, GL, Hetzner) and none is nowhere close in terms of darkness/saturation.
Not saying that my proposed choice is a good alternative but I really think the current one is sub-optimal.)

[pat-s]

#4584 (comment) - guess I'll have to close this PR?

[xoxys]

I dont think so, Im fine with a color change.

[xoxys]

Im also fine with the not-desaturated color, just dont had time to come back to this PR.

[xoxys]

The desaturated looks now more pink in dark mode. Then I would prefer your initial one.

[pat-s]

The desaturated looks now more pink in dark mode. Then I would prefer your initial one.

Still trying. Iterating in the PR, not locally.
Adding saturation wasn't a good idea.

[xoxys]

Ok, sorry. Hard to see what is "developing commit" and whats not. Is there a reason not to use a local compose stack to test your changes? Just wondering as for me the feedback loop would be way too long otherwise.

[pat-s]

Ok, sorry. Hard to see what is "developing commit" and whats not. Is there a reason not to use a local compose stack to test your changes? Just wondering as for me the feedback loop would be way too long otherwise.

When you iterate on 4+ PRs, letting the CI build everything and then just kill the pod is the simplest way imo (my dev instance is on k8s). I sometimes build local images but only until I am convinced this is worth a PR and the CI build actually working (and it is not a UI PR).

I think building UI PR images publicly is important as others can easily apply the images this way and verify changes in detail.

[xoxys]

I just tested colors.red[500] and IMO it is pretty close to the custom color you selected. I Would just use this one for the dark mode and drop the desaturation.

[pat-s]

I just tested colors.red[500] and IMO it is pretty close to the custom color you selected. I Would just use this one for the dark mode and drop the desaturation.

Hm, that's how I started out initially but wasn't convinced...but ok, I'll try again.

[xoxys]

Yeah, it is not exactly the same color of course, but Im wondering if the minimal difference is really important. Btw we have also introduced theming by custom css to adjust such things to personal preferences without code changes.

[pat-s]

OK, this one works for me. Updated the screenshot in OP.

[xoxys]

Would wp-state-error-200 instead of wp-state-error-100 in dark mode work for you as well? Can we also remove 400: 'var(--wp-state-error-400)' and 500: 'var(--wp-state-error-500)', for wp-state-error again? It's not uses anywhere.

[pat-s]

Can we also remove 400: 'var(--wp-state-error-400)' and 500: 'var(--wp-state-error-500)', for wp-state-error again?

The idea that was to have a larger palette defined for potential future uses that allows colors below and above the current active spectrum. (Yes, I know that the "below" part is actually missing). AFAIK there are also not all green primary colors in use which are defined?
But to move on and to avoid further discussions, I'll remove them.

Would wp-state-error-200 instead of wp-state-error-100 in dark mode work for you as well?

OK.

[pat-s]

@xoxys Your turn again.

[xoxys]

Just a nit. Maybe we should also rename wp-state-error to wp-error as we now use it in multiple different locations? Can also be done in a separate PR.

[woodpecker-bot]

Deployment of preview was torn down

[xoxys]

@pat-s there are open suggestions

[xoxys]

There are still a lot of wp-state-error occurrences that were not renamed properly.