WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 4 years ago

#18314 closed task (blessed)

Merge admin CSS files and remove duplicates — at Version 14

Reported by: azaozz Owned by:
Milestone: 3.3 Priority: normal
Severity: normal Version:
Component: Performance Keywords:
Focuses: Cc:

Description (last modified by 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

Change History (15)

comment:1 follow-up: @scribu4 years ago

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

comment:2 @azaozz4 years ago

  • Description modified (diff)

comment:3 in reply to: ↑ 1 @azaozz4 years ago

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.

Last edited 4 years ago by azaozz (previous) (diff)

comment:4 @scribu4 years ago

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?

comment:5 @scribu4 years ago

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

If anything, it would make it easier.

comment:6 @azaozz4 years ago

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.

comment:7 follow-up: @scribu4 years ago

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.

comment:8 in reply to: ↑ 7 @azaozz4 years ago

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.

comment:9 @sabreuse4 years ago

  • Cc sabreuse@… added

comment:10 @andrewryno4 years ago

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.

comment:11 @nacin4 years ago

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

comment:12 @azaozz4 years ago

In [18577]:

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

comment:13 @azaozz4 years ago

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

comment:14 @azaozz4 years ago

  • Description modified (diff)

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.

Last edited 4 years ago by azaozz (previous) (diff)

@ryanimel4 years ago

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

Note: See TracTickets for help on using tickets.