Opened 9 years ago
Closed 22 months ago
#35783 closed enhancement (fixed)
The WordPress shades of grey
Reported by: | afercia | Owned by: | |
---|---|---|---|
Milestone: | 4.5 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Administration | Keywords: | has-patch has-screenshots |
Focuses: | ui, css | Cc: |
Description
A while ago there was a conversation on Slack about the multitude of grays used in the WordPress admin. Wondering about a tool capable of extracting colors and return some usage data, we tried cssstats. Far from being a scientific method, I've just uploaded the concatenated and minified CSS file and got some results.
I'm pretty sure cssstats doesn't get all the colors but the data report is an interesting summary of the WordPress CSS (as of January 26th, 2016). There are many interesting points to consider, for example the media queries total number, but let's focus just on colors for now and more specifically on grays.
Looks like there are more than 40 different shades of grays, not counting the rgba ones and the ones that cssstats probably missed. It's totally understandable that in a so large project, with time, year after year, some things get missed and some colors stay in the CSS without particular reasons other than historical ones. By the way, for the sanity of the CSS in the long run, I'd recommend to audit all these shades of gray and try to reduce their total number as much as possible.
About backgrounds, this would have beneficial effects also when trying to find accessible colors for links (hover, focus states included) and other controls. Finding suitable colors against, say, 20 different gray backgrounds would be a bit hard. Reducing the gray backgrounds to a small, known, number would greatly help. Not to mention design consistency and the ongoing effort to make WordPress use a well established, standardized, color palette.
Working a bit on the cssstats results, I've split the grays in different groups, just scanning the WordPress CSS files and trying to check how many times they're used and where. Again, this doesn't pretend to be a scientific method :) for that, maybe there would be the need of some more reliable tools other than cssstats.
The grays in the first group are used in only one CSS ruleset and I'd say they should be definitely standardized and replaced with other grays. The ones in the second group have just two occurrences and they should probably be standardized too. Third and fourth group: to evaluate :)
One occurrence
2f2f2f - for .theme-browser .theme.active .theme-name 686868 - .theme-overlay .theme-author 808080 - suggest.js auto suggestions border grey - .media-disabled, .imgedit-settings .disabled 9a9a9a - old media upload? to move to deprecated media css bbb - media upload dashicon upload-dismiss-errors, also tinymce "lightgray" skin d2d2d2 - borders for .tablenav .tablenav-pages a, .tablenav-pages-navspan ececec - background for #plugin-information .counter-back (star rating in the plugin details modal) e7e7e7 - .media-icon img fallback border for rgba border, remove both? f4f4f4 - "undo" table row background, maybe unify with a more used background like f5f5f5 ?
Two occurrences
101010 - suggest.js auto suggestions text color list on white or #f0f0b8 background (also on Press This) a9a9a9 - input placeholder, there's a ticket for this, see #35777 b4b4b4 - tablenav-pages-navspan and the pressthis-bookmarklet link dadada - (excluding deprecated media css) only for borders, maybe unify with more used borders ? d7d7d7 - revisions borders, also tinymce "lightgray" skin e6e6e6 - #plugin-information .review, press this, also tinymce "lightgray" skin, to unify with e5e5e5 ?
Have very similar colors, maybe should be unified
464646 - unify with 444 ? dedede - mainly borders and .wp-playlist-dark .wp-playlist-caption, maybe unify with dfdfdf ? dfdfdf - mainly borders, maybe unify with dedede ? e4e4e4 - used very few times, maybe unify with e5e5e5 ?
Used very few times, to evaluate
222 - .edit-comment-author text and wp-embed and mediaelement background, maybe change to #23282d ? 727272 - maybe change to 72777c ? ebebeb - used very few times fbfbfb - manage-menus (toolbar in menus screen) and login form, very close to white fdfdfd - tab panels eaeaea - only for `kbd` and `code` backgrounds e8e8e8 - border for list table pagination links and few other things e1e1e1 - a very few borders and shadows
Other grays
444 - main text color 555 - maybe should be replaced with the new 555d66 ? 555d66 - new gray 666 - mainly for text color 999 - there's a ticket for text color, see #35660 but it's also used for borders ccc - mixed use, text, borders, backgrounds, shadows c4c4c4 - only in the gradient for #postimagediv .inside img ddd - mainly borders and a few backgrounds eee - mixed use, most notably: main Customizer background e5e5e5 - mixed use, mainly borders fcfcfc - backgrounds f1f1f1 - main background f3f3f3 - backgrounds f5f5f5 - backgrounds f7f7f7 - backgrounds f9f9f9 - backgrounds, zebra striping and others
Attachments (3)
Change History (32)
This ticket was mentioned in Slack in #design by afercia. View the logs.
9 years ago
#3
follow-up:
↓ 4
@
9 years ago
Seems to me like creating color-based classes for the admin areas would be a helpful way to keep color consistent across even multiple color schemes. If there is one .sidebar class that defines the area, regardless of what color that class represents and we had admin themes that built off those classes, you could define colors in a single location.
#4
in reply to:
↑ 3
;
follow-ups:
↓ 5
↓ 9
@
9 years ago
Replying to DragonFlyEye:
Seems to me like creating color-based classes for the admin areas would be a helpful way to keep color consistent across even multiple color schemes. If there is one .sidebar class that defines the area, regardless of what color that class represents and we had admin themes that built off those classes, you could define colors in a single location.
I think Will be also usefull create a sort of "Wordpress Graphics Standard", a manual where everyone can reference when contributing in the design branch of the project
#5
in reply to:
↑ 4
@
9 years ago
Replying to Playrom:
Replying to DragonFlyEye:
Seems to me like creating color-based classes for the admin areas would be a helpful way to keep color consistent across even multiple color schemes. If there is one .sidebar class that defines the area, regardless of what color that class represents and we had admin themes that built off those classes, you could define colors in a single location.
I think Will be also usefull create a sort of "Wordpress Graphics Standard", a manual where everyone can reference when contributing in the design branch of the project
No question. A design standard similar to the theme coding standard, IOW.
#7
in reply to:
↑ 6
@
9 years ago
Replying to netweb:
See also https://wordpress.org/about/logos/ and http://codepen.io/hugobaeta/full/RNOzoV/
Wow. I have _never_ seen those before.
#8
in reply to:
↑ 6
@
9 years ago
Replying to netweb:
See also https://wordpress.org/about/logos/ and http://codepen.io/hugobaeta/full/RNOzoV/
https://wordpress.org/about/logos is severely outdated... I need to update it with info from https://make.wordpress.org/design/handbook/foundations/identity/
#9
in reply to:
↑ 4
;
follow-up:
↓ 11
@
9 years ago
Replying to Playrom:
I think Will be also usefull create a sort of "Wordpress Graphics Standard", a manual where everyone can reference when contributing in the design branch of the project
It's WordPress (Capital P, dangit!). And we have Design Handbook, or at least the foundations of it in https://make.wordpress.org/design/handbook/
#10
@
9 years ago
So, we've got the standards or at least the framework to track them. For this ticket, I guess, this is just a question of running down grey colors that do not conform to the six listed there? (and yes, I promise I'm about to read the Core Handbook right after I'm done commenting..)
https://make.wordpress.org/core/handbook/
#11
in reply to:
↑ 9
@
9 years ago
Replying to hugobaeta:
Replying to Playrom:
I think Will be also usefull create a sort of "Wordpress Graphics Standard", a manual where everyone can reference when contributing in the design branch of the project
It's WordPress (Capital P, dangit!). And we have Design Handbook, or at least the foundations of it in https://make.wordpress.org/design/handbook/
Never Seen that page! It's a good start!
#12
@
9 years ago
- Keywords has-patch added; needs-patch removed
A first patch that takes care of the grays in the first group and also the #101010
because it's used for the color text of the suggest.js
suggestions. About the list of suggestions, I'd propose to style it as proposed in #33902 see https://cldup.com/E51OPwBpeP.png can be changed to a simpler style of course. Any thoughts more than welcome.
Sass, color-based classes, etc. are great tools and still under discussion. I'd keep it simple for now and just start patching :)
This ticket was mentioned in Slack in #design by afercia. View the logs.
9 years ago
#15
@
9 years ago
Second patch, for the second group. Will upload a screenshot with a couple of interesting cases soon.
#16
@
9 years ago
In this second patch, one interesting thing is the styling related to .side-info
. Looking for some reference in the code, found it was used for WordPress pre-2.7 and then removed, couldn't find any usage on the current codebase:
I'd say these rules can be safely removed, unless I'm missing something.
I'd also propose to change the colors of the list table pagination disabled links, to make them use the same colors of the disabled buttons. See in the screenshot below, where the "Search Posts" button is disabled just for testing purposes. This would introduce a bit of consistency for inactive controls. About accessibility, text that is part of an inactive user interface component has no contrast requirement.
This ticket was mentioned in Slack in #design by afercia. View the logs.
9 years ago
#19
@
9 years ago
- Keywords has-screenshots added
New patch to take care of the grays in the 3rd group. Proposed changes:
- all the
#464646
(mainly text color) replaced with#444
#dedede
and#dfdfdf
(mainly borders) replaced with#ddd
: they're so close and they're quite a lot#e4e4e4
used just 4 times, replaced with#e5e5e5
Side note: the patch completely removes stuff related to:
#wphead
: no more used in the admin, was used on the old Press This- some of the
.inside-submitbox
stuff: was part of Crazyhorse, see [8691] probably used only in trunk, first commented out and then removed in [9394] .submitbox .submit
box stuff: was used in WordPress pre-2.7 when the Edit Post "Save" box had a dark gray background, see screenshot below
I'd appreciate feedback from someone with historical knowledge of the CSS but as far as I see they should be safe to remove. cc @helen
#22
@
9 years ago
About release cycle schedule, this is probably a ticket that will be completed during 4.6 unless someone wants to take a stab at it and fix everything in the next days. This "someone" would be very, very, welcomed :)
This ticket was mentioned in Slack in #design by hugobaeta. View the logs.
8 years ago
This ticket was mentioned in Slack in #design by hugobaeta. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by hareesh-pillai. View the logs.
5 years ago
This ticket was mentioned in Slack in #core-css by afercia. View the logs.
5 years ago
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
5 years ago
#28
@
3 years ago
Does the standardization of WP-Admin colors in 5.7 fulfill the need in this ticket? The greys used in the CSS have been reduced to only those that are part of the color palette.
I think that's definitely a problem! It's inconsistent and there will be a lot more shades in the future if we don't fix this now.
It's a viable way to start using sass in the coming releases? This is one of the problems that could be fixed with a CSS preprocessor