Make WordPress Core

Opened 9 years ago

Closed 22 months ago

#35783 closed enhancement (fixed)

The WordPress shades of grey

Reported by: afercia's profile 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)

35783.group01.patch (4.1 KB) - added by afercia 9 years ago.
35783.group02.patch (3.3 KB) - added by afercia 9 years ago.
35783.group03.patch (18.3 KB) - added by afercia 9 years ago.

Download all attachments as: .zip

Change History (32)

This ticket was mentioned in Slack in #design by afercia. View the logs.


9 years ago

#2 @Playrom
9 years ago

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

#3 follow-up: @DragonFlyEye
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: @Playrom
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

Last edited 9 years ago by Playrom (previous) (diff)

#5 in reply to: ↑ 4 @DragonFlyEye
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 @DragonFlyEye
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.

#9 in reply to: ↑ 4 ; follow-up: @hugobaeta
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 @DragonFlyEye
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 @Playrom
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 @afercia
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

#14 @afercia
9 years ago

In 36537:

Accessibility: Reduce the WordPress shades of grey, first part.

See #35783.

#15 @afercia
9 years ago

Second patch, for the second group. Will upload a screenshot with a couple of interesting cases soon.

#16 @afercia
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:

https://cldup.com/QioRavB-pm.png

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.

https://cldup.com/FnvwqtcZi5.png

Last edited 9 years ago by afercia (previous) (diff)

This ticket was mentioned in Slack in #design by afercia. View the logs.


9 years ago

#18 @afercia
9 years ago

In 36582:

Accessibility: Reduce the WordPress shades of grey, Episode 2.

See #35783.

#19 @afercia
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

https://cldup.com/rEc760NFY5.png

#20 @helen
9 years ago

Remove it. :)

#21 @afercia
9 years ago

In 36904:

Accessibility: Reduce the WordPress shades of grey, Episode 3.

Also, removes some no more used CSS.

See #35783.

#22 @afercia
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 @notlaura
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.

#29 @sabernhardt
22 months ago

  • Focuses css added
  • Milestone set to 4.5
  • Resolution set to fixed
  • Status changed from new to closed

I'm closing this as fixed. Any further changes could have a new ticket.

Note: See TracTickets for help on using tickets.