Merge admin CSS files and remove duplicates

[azaozz]

Looking through wp-admin/css we have large amount of stylesheets that aren't optimized neither for loading nor for maintenance/consistency.

Generally we have two options: either to break our CSS into smaller chunks of dependent styles and load different amount on each screen or to "globalize" it all into wp-admin.css and wp-admin-rtl.css.

The second option would be (quite?) better for faster loading. Currently we concatenate and compress the admin css but since the files are different for most screens, the concatenated file has to be downloaded each time. If all admin styles are in one file it will be cached by the browser after the first time (in memory) and all subsequent loads will be faster.

To do:

• continue removing duplicate and nearly duplicate styles from wp-admin.css
• after that's in good shape, do the same for wp-admin-rtl.css

Please see comment:14

[scribu]

-1 on putting it all in wp-admin.dev.css.

Currently we concatenate and compress the admin css but since the files are different for most screens, the concatenated file has to be downloaded each time.

Ok, then let's serve all the files all the time, concatenated.

[azaozz]

Replying to scribu:

-1 on putting it all in wp-admin.dev.css...
Ok, then let's serve all the files all the time, concatenated.

What's the point of having 20 files then? Apart from making it harder to debug :)

Actually if we put all in wp-admin.css we can turn concatenation for admin css off, only keep compressing it.

Ugh, we actually have 33 files there, including the -rtl.css.

[scribu]

What's the point of having 20 files then? Apart from making it harder to debug :)

wp-admin.dev.css already has 4700+ LOC.

By that same token, what's the point in having separate PHP files then?

[scribu]

And I don't see how having separate CSS files would make it harder to debug.

If anything, it would make it easier.

[azaozz]

If only PHP could cascade like CSS... :)

Apart from slowing down the browser loading, having many smaller CSS files has several drawbacks: much harder to reuse styles, harder to track duplicates, harder to maintain proper "cascading", etc. I think we can eliminate about 1/5 to 1/4 of the total CSS LOC if we do proper removal of duplicate styles.

[scribu]

I'm totally for removing duplicate styles.

much harder to reuse styles

How so? There's reusing and then there's clumping together unrelated elements.

harder to track duplicates

Maybe, but not if we split the files by components: general layout, list tables, form elements etc.

harder to maintain proper "cascading"

Huh? Please give an example.

[azaozz]

Replying to scribu:

much harder to reuse styles

How so? There's reusing and then there's clumping together unrelated elements.

CSS doesn't care whether elements are related or not. If we repeat

border-width: 1px;
border-style: solid;

in 20-30 places, that's duplication.

harder to track duplicates

Maybe, but not if we split the files by components: general layout, list tables, form elements etc.

So if a style is defined in list-tables.css and you're adding something on the Add New post screen that can use it, what do you do? Do you add the selector to list-tables.css and "break the flow" or do you define (copy) the style to add-new-post.css?

harder to maintain proper "cascading"

Huh? Please give an example.

See above. If we start mixing what CSS applies on which screen, it can get messier.

Generally the question is: is it easier to maintain one large css file or 20 small files (that will always be outputted together)? IMHO one large file is easier.

[andrewryno]

I would like to get started on this. Could we agree to at least merge the *-rtl.css files into the main .css files (with using the .rtl body class)?

This would make it easier to edit RTL styles because you could include the RTL style directly after the non-RTL style (grouping them together). I can provide a patch tomorrow if we would like to start with that.

[nacin]

There's something like 36k across the RTL files. It'd be better to combine them all into one rtl.css file.

[azaozz]

In [18577]:

Merge most admin css files, first run, see #18314

[azaozz]

In [18578]:

Merged install.css with install-rtl.css (it is used only when installing so it makes sense to be a separate stylesheet), merged farbtastic.css with farbtastic-rtl.css, see #18314

[azaozz]

There are still quite a few duplicates or nearly duplicates in wp-admin.css. All are welcome to help slim it down. The only thing we need to be careful about is to apply any uncommited patches to it before starting to hunt for duplicates. It's hard to merge conflicting css patches as each conflict has to be tested separately.

[ryanimel]

This patch combines the colors-classic.css with colors-classic-rtl.css, and same for the fresh colors. Also added some basic commenting.

[ramoonus]

this makes script_debug in wp-config obsolete?

[azaozz]

In [18579]:

Merge colors*.css with colors*-rtl.css, props ryanimel, see #18314

[SergeyBiryukov]

[18577] introduced the dependency between ie.css and wp-admin.css. It breaks the layout of database upgrade page (see the screenshot), since wp-admin.css shouldn't be included there.

18314.ie.patch​ removes the dependency.

[SergeyBiryukov]

Due to [18578], we need to set <body class="rtl"> in install.php (also in setup-config.php, but that should be adressed in #18180) if is_rtl().

Added a patch for that.

[markjaquith]

[18577] broke the DB upgrade screen:

​http://cl.ly/1A2x1E0j0W1r053N3v0J

[SergeyBiryukov]

Replying to duck_:

I was wondering why this style is restricted to body.nav-menus-php when others are not...

Probably because the class .item-order is used on other screens too and this interferes with them.

Also [18577] dropped the CSS reset entirely.

CSS reset is necessary/good to have when supporting older browsers (IE6, FF2, etc.) as they have wildly different default styling. All newer browsers have very similar styling, so instead of resetting everything to some kind of zero values we only need to define global styles for the elements we need.

You're right we are missing DL from the UL and OL style :)

Edit: Actually all browsers have 1m top and bottom margin on DL, UL and OL. If we need to remove it somewhere we should target that specifically.

[dd32]

In [18622]:

Mark the install page as rtl for styling purposes. Props SergeyBiryukov. See #18314 and #18180

[azaozz]

In [18719]:

Remove dependency from ie.css, props SergeyBiryukov, see #18314

[azaozz]

In [18728]:

Merge all border-radius: 3px, see #18314

[SergeyBiryukov]

Related: ticket:18197:18197.remove-userinfo.2.patch​ (removes obsolete user info styles)

[azaozz]

In [18729]:

Add the borders to the border-radius merge, see #18314

[azaozz]

Fix scrollbar on the login screen

[azaozz]

In [18737]:

Remove the scrollbar from the login screen, see #18314

[scribu]

Related: #18740

[kirasong]

Combine H1/H2/H3... and Approve/UnApprove styles

[azaozz]

In [18744]:

Remove some duplicates and combine some css selectors, props DH-Shredder, see #18314

[duck_]

18314.hide-menu-ordering.diff will hide the menu item ordering arrows when JS is enabled. I was wondering why this style is restricted to body.nav-menus-php when others are not, e.g. .js .input-with-default-title.

Also [18577] dropped the CSS reset entirely. It was previously in global.css which is no more. One problem this has caused can be seen on the nav menus page: expanded menu items have a gap between the header and the drop down holding the settings. In Chrome this is caused by the 1em margin on dl elements.

[kirasong]

Combine Duplicate #wp-fullscreen-save definitions and remove extra style from .post-com-count span

[nacin]

In [18759]:

Combine some CSS definitions. props DH-Shredder, see #18314.