[wp-trac] [WordPress Trac] #49999: Iterating on Admin Color Schemes
WordPress Trac
noreply at wordpress.org
Wed Feb 10 21:26:59 UTC 2021
#49999: Iterating on Admin Color Schemes
---------------------------------------+-----------------------------------
Reporter: ryelle | Owner: ryelle
Type: task (blessed) | Status: assigned
Priority: normal | Milestone: 5.7
Component: Administration | Version:
Severity: normal | Resolution:
Keywords: needs-dev-note needs-docs | Focuses: ui, accessibility,
| css
---------------------------------------+-----------------------------------
Comment (by johnjamesjacoby):
@ryelle hey there! I've attached 3 screen shots of some unique styling in
Sugar Calendar.
It is my hope that these screen shots will help highlight ways that
plugins have needed to copy existing color scheme colors to integrate them
into their own designs. The red squares draw attention to color scheme
specific CSS included in a single plugin that will need to be changed to
match the updated colors in 5.7.
(As a preface, I empathize with why these changes were deemed necessary. I
understand that admin styling can and will change. I understand that
plugins take or certain risks and responsibilities when opting into
supporting admin color schemes. Ultimately, I will make sure my plugins
work with all WordPress versions, because I believe it's the right thing
to do. It is not my intent to diminish anyone's efforts. I only hope to
provide contextual feedback about the result of them in my specific
field.)
Because, as we know, WordPress does not (currently) supply simple semantic
classes that can be easily applied to custom UI elements (think `.left-
border-fresh` or something), and because there are no variables that
plugins can easily use, every plugin needs to do their own due diligence
to make sure their custom UI elements fit in with all color schemes. It's
not enough to just assume "Fresh" or blue all of the time, everywhere.
This means when changes are made to WordPress core color scheme styling,
plugins usually will not automatically inherit very much of those color
changes, and is likely a major reason behind why colors are changed so
infrequently. (Previous changes in (I think?) 5.2 caused a similar set of
maintenance problems.)
The batch of changes related to this specific issue introduces some unique
challenges for all plugins who add support for the core color schemes, and
I'll try to number them below:
1. If the goal for 5.8 and later is to use CSS variables, that makes the
5.7 release a single unique approach to CSS styling. That means plugins
will need to support 3 different styling decisions: 5.6 and earlier, 5.7,
and 5.8 and later.
2. Slightly tweaking the colors between versions means that schemes like
"Fresh" and "Blue" ultimately mean something different for 5.6 and
earlier, and 5.7 and later. Using the API as intended, I would expect the
changed schemes to be "Fresh Modern" or "Blue Modern" or something else.
They are simply different schemes, albeit very similar to their 5.6-and-
earlier siblings.
3. I acknowledge that very few users or people will notice. Of those who
do notice, even fewer will complain to me about the colors of my plugins
being slightly off. But, these small changes echo through-out the plugins
who are working hard to provide the very best experience to their users,
resulting in doubling or tripling the effort required for 5.8.
I'm not in a position to make a recommendation on anything that can or
should change in the 5.7 release cycle to improve any of my findings. I
don't think it makes sense to revert anything, or wait until 5.8,
especially since this has been soaking in trunk for a while now, and I'm
the only one with this perspective so far. It's safe to say the footprint
is relatively small.
Thank you for reading 💙
--
Ticket URL: <https://core.trac.wordpress.org/ticket/49999#comment:113>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list