Merge the default colors css into wp-admin.css

[azaozz]

As the title.

[ryan]

Actually, wontfix until we are committed to this direction.

[koopersmith]

​In IRC, Jane suggested making gray the only color scheme and moving any other color scheme (blue, and potentially a high-contrast color scheme) into a plugin integrated into the UI. I heartily support that suggestion.

[DrewAPicture]

Replying to koopersmith:

In IRC, Jane suggested making gray the only color scheme and moving any other color scheme (blue, and potentially a high-contrast color scheme) into a plugin integrated into the UI. I heartily support that suggestion.

+1

[helen]

#24806 was marked as a duplicate.

[jorbin]

The above patch removes colors.css from being loaded, but only when we are using the default color scheme. I also started on integrating colors.css into wp-admin.css

[helen]

We're committed to this direction now. It was discussed in IRC, though I am not having luck finding the exact link (my own fault for not doing this earlier). Would be thankful to anybody who can dig it up - it was within the last couple of weeks.

The redesign of 3.8 makes this a much better idea. The default colors.css is @import-ed into each of the alternate color schemes. When using unminified files, this means an extra HTTP request, and a slow one at that. When using minified files, cssmin/clean-css actually inlines the entire file into every single color scheme's colors.css. This makes avoiding a rebuild in point releases very difficult, and now that it is a true overload as opposed to a swap, makes much more sense to merge into the main wp-admin.css file.

Other benefits include:

• A lower barrier to entry for first-time admin CSS patches. It is less than fun to edit a border width and style in one file, and the color in another.
• We will likely reduce file size due to being able to use more shorthand properties. At worst, the size will remain about the same, but there will be no more colors.css to add to that.

There is an _admin.scss file that has to be maintained, and of course consideration for each of the color schemes. However, _admin.scss is already quite diverged from colors.css, so it would be a hand-maintained file from this point forward, anyway.

Once this is complete, we will tackle #26669.

[helen]

Been dumping a diff of work at stopping points onto the ticket, for the curious - this is a lot of heartache.

[helen]

In 27106:

Merge colors.css into wp-admin.css. Non-default color schemes became overloads rather than swaps in the 3.8 redesign. Benefits include:

• No more border-width, border-style, border-color insanity.
• Point releases are much less likely to require extra finagling to avoid rebuilding the color schemes.
• Yours truly has a better overall vision of ~14,000 lines of admin CSS and where we go from here.

1,065 net lines of red, y'all.
props helen, jorbin. fixes #18380.

[helen]

In 27107:

Some tweaks to [27106]:

• Add more @todo markings and remove one that's been resolved.
• Restore a missing comma in a .wp-badge background rule, and add a comment reminding us why it's there.

see #18380.

[ocean90]

This needs a change in register_admin_color_schemes(), see 18380.patch​. Otherwise you get a 404 for colors.css.

Not yet tested in build.

[helen]

In 27109:

Fix some hover/focus styling and specificity issues. see #18380.

[nacin]

In 27111:

Fix the conditional enqueueing/printing of colors stylesheets, without breaking dependencies.

fixes #18380.
see #20729 which should properly fix this.

[helen]

In 27772:

Make sure inputs in Press This have a type so they are styled appropriately. see #18380.

[helen]

In 27832:

Correct cascade issues and remove some unused CSS for the admin menu. see #18380.

[helen]

In 27852:

Restore some CSS rules that are necessary for non-default schemes. see #18380.