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]

Yep, 18314.ie.patch Download should fix this.

(Didn't mean to edit this comment. Seems there's a bug on trac as the comment numbers are not right on this ticket.)

[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.

[azaozz]

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 :)

[duck_]

Replying to azaozz:

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.

I though that too, but searching for "item-order" I couldn't find any other instances. As of [18755] that .item-order styling is redundant and can be removed anyway.

[azaozz]

Replying to duck_:

As of [18755] that .item-order styling is redundant and can be removed anyway.

Patches for anything like that are always welcome (anything like that = styling that is redundant because of another change but wasn't removed with the other commit).

[duck_]

In [18770]:

Remove .js .item-order style made redundant by r18755. See #18314.

[azaozz]

In [18772]:

Fix line-height inside postbox and stuffbox, see #18314

[ocean90]

18314.fonts.patch will combine the font-families and removes some unused lines.

[azaozz]

In [18872]:

Combine font-family, remove few unused bits, props ocean90, see #18314

[olleicua]

Combining rules under /* 2 columns main area */ in wp-admin.css

[olleicua]

This is my first WordPress patch so please let me know if there is something wrong with it: ​18314.combineColumnContainers.diff
~Peace

[olleicua]

Replying to 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.

Is there an easy way to see which patches have been committed besides actually reading each diff and looking to see if the changes are already there?
~Peace

[azaozz]

In [18903]:

Combine few styles for column containers, props olleicua, see #18314

[azaozz]

Replying to olleicua:

This is my first WordPress patch so please let me know if there is something wrong with it...

No, all is good, thanks.

Is there an easy way to see which patches have been committed besides actually reading each diff and looking to see if the changes are already there?

Sure, if you add your email to Trac preferences, you will get a notification of all subsequent comments on tickets you commented on including all commit messages.

[dd32]

I'm seeing a few styling issues, not sure if it's related to this ticket or not:

• IE: Add new Media buttons above TinyMCE has a thick border
• General: Iframes seem to have an inset edge (The default?), whereas previously they were styled similar to textarea's (With regard to the border at least)

[dd32]

looks like iframe lost it's border:0 as it wasn't brought over from the reset in global.css, Spotting a few other a > img with borders elsewhere too (add_menu_page() items which don't specify a icon)

As for where I'm getting the iframe from, i'm using the 'Debug Bar Console' plugin which uses a inline iframe.

[scribu]

Probably related: #18901

[olleicua]

various cleaning/combining in wp-admin/css/wp-admin.dev.css

[olleicua]

Did a once over of wp-admin.css trying to clean things up a bit. There's probably a lot I missed.

[olleicua]

Thanks

Replying to azaozz:

Replying to olleicua:

No, all is good, thanks.

Sure, if you add your email to Trac preferences, you will get a notification of all subsequent comments on tickets you commented on including all commit messages.

[azaozz]

In [18939]:

More CSS cleanup, props olleicua, see #18314

[andrewryno]

18314.wphead-favorites-misc.diff gets rid of a lot of #wphead rules since the new admin bar was put in (leaves in stuff for Press This), #favorite-actions and the old editor buttons (new rules in editor-buttons.css).

[azaozz]

In [18975]:

RTL, IE7 and IE7 RTL fixes, add class="ie8" to the html tag, see #18314

[azaozz]

In [18976]:

Clean up styles for #wphead, #favorite-actions and the old editor buttons, props andrewryno, see #18314

[duck_]

Replying to azaozz:

In [18975]:

RTL, IE7 and IE7 RTL fixes, add class="ie8" to the html tag, see #18314

[18977] Fix notices in wp_iframe() and iframe_header() by referencing $wp_htmltag_class as a global. See r18975 and #18314

[azaozz]

Replying to duck_:

Thanks, meant to do that before committing :)

[scribu]

Related: #18966

[ramiy]

Some changes break the RTL admin.

wp 3.2.1:

wp 3.3 beta1-18972:

[andrewryno]

Use category/tag styles from postscreen with only minor changes

[andrewryno]

attachment:18314.press-this.diff​ adds an ID to the press-this sidebar so it can use the styles for the regular post screen and then only changes the dimensions so it still fits within the window. Also gets rid of some other styles that are already defined for the main post screen.

[azaozz]

In [19001]:

Press This CSS cleanup, props andrewryno, see #18314

[azaozz]

In [19090]:

Some more css cleanup, see #18314

[azaozz]

In [19116]:

More css cleanup, fix styles in the Edit Image popup then the editor is on the front end see #18314

[azaozz]

Close as fixed for now. More to come in 3.4.

[azaozz]

In [19227]:

Fix styling in the MCE help popup, see #18314