Refactor system/base library

I took a stab at it and refactored most of the css that should be refactored. The remainder of css were not specific to any templates and/or were too broad and used in multiple areas of Drupal.

One important thing I noticed is that some themes (core themes included) are using libraries-override to override some of the css in the system/base library. I don't think it will break anything, but the css it will try to find will not exist.

For e.g. in claro.info.yml:

libraries-override:
  system/base:
    css:
      component:
        css/components/ajax-progress.module.css: css/components/ajax-progress.module.css
        css/components/autocomplete-loading.module.css: css/components/autocomplete-loading.module.css
        css/components/system-status-counter.css: css/components/system-status-counter.css
        css/components/system-status-report-counters.css: css/components/system-status-report-counters.css
        css/components/system-status-report-general-info.css: css/components/system-status-report-general-info.css
        css/components/tabledrag.module.css: css/components/tabledrag.css

In the above code, all of the source system-status-...css will be missing if this MR were to be merged.

What should we do about these kinds of cases?

MR has failures.

From @nod_

Seems like we could move the details css file to the drupal.collapse library too no? it's a pretty big file in claro.
Same for sticky-header.module.css that could go into drupal.tableheader maybe?

Don't think these are already included here, so adding to make sure they get included.

Also bumping priority here because this is a significant front end performance improvement for any sites that hasn't manually excluded these files itself to get the same effect.

catch → changed the visibility of the branch 2880237-refactor-systembase-library to hidden.

Now 📌 Move system/base component CSS to respective libraries where they exist Fixed is in, trying to revive this one.

I've started a new MR because the approach is different. The original approach here used attach from templates, however template overrides would not get the library added so it seemed risky from a bc standpoint. Instead I've moved files between libraries where possible, or if there wasn't an appropriate library (system status et al) into a new library then using #attached in the render element.

Covered in the MR:

A new system status report library attached from the status report render element.

details.module.css moves to core/drupal.collapse

sticky-header.css moves to core/drupal.tableheader

A new core/drupal.item_list library attached from the item_list element.

A new core/drupal.resize library attached from the textarea element.

Starterkit's tabledrag styling hadn't moved in the previous MR, moved that here.

Extra things I found:

Claro's views styling should probably be a libraries-extend of one of the views UI libraries.

We can re-use the system/base change record we already have as long as this lands in 10.3.x. Tagging for that, and I'll add the suggested text additions to the issue summary once tests are green.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Rebased.

This is a solid 2kb reduction in CSS payload for most pages now (uncompressed).

I'm all for this, can a CR be written up?

@smustgrave there's an existing CR for the previous issue at https://www.drupal.org/node/3432346 →

Since this issue is very similar, I was planning to copy the API changes section of this issue over to that CR once this is committed, as long as it lands in 10.3.x

few typos in the library names

pradhumanjain2311 → made their first commit to this issue’s fork.

With the patch in the current version (using claro):

1. item list style missing /admin/reports/fields, the new library is never attached anywhere
2. tablesort indicator icon missing on claro /admin/content?title=&type=All&status=All&langcode=All&order=status&sort=asc this might need to be a follow-up, looks tricky.
3. no style on status page /admin/reports/status
4. There are image paths inside the CSS files that needs to be updated since the path of the css file changed.
5. Textarea resize styles not applied /admin/structure/types
6. Haven't found a test case for fieldgroup but that won't work either

The 2kb makes sense, there is a bunch of file that should be loaded that are not :D

container-inline.module.css could also be moved, and then attached somewhere in the container chain.

Given the amount of bugs found in #40, and the amount of merge conflicts here after a few months, I think we should split this into individual issues by destination library. Will be easier to verify that way.

Switching to a meta/plan.

First issue needs review: 📌 Move status report assets to their own library Active

Next one: 📌 Move resize CSS into its own library Active .

Since these all need manual testing and conflict with each other, definitely better to do library-by-library.

📌 Move fieldgroup CSS to its own library Active theoretically won't conflict with 📌 Move resize CSS into its own library Active so added that too.

Added 📌 Move details.css to the collapse library Active because that also shouldn't conflict hopefully.

From the original MR here, this leaves:

Sticky tableheaders - already done in 📌 Make drupal.tableheader only use CSS for sticky table headers Needs review

Tablesort - needs work issue already at 📌 Split tablesort.module.css out to its own library and attach it via tablesort Active

item-list - @todo.

That's everything split out to its own issue now.

Of the remaining files:

clearfix.module.css - class is used by multiple core demplates.
align.module.css - used various places in core, but we should remove the views duplicates: 📌 Remove the views-align-* CSS classes Active
container-line.module.css - used in lots of places.
hidden.module.css - used a lot
js.module.css - used a lot
nowrap.module.css - can't see where this is used at all, maybe we can deprecate/drop it.
position-container.module.css - one usage in claro, could maybe be factored out.
reset-appearance.module.css - one usage in claro, could be factored out.

Getting close to 1kb of CSS once remaining issues are in, this is down from 7kb originally.

Getting close to 1kb of CSS once remaining issues are in, this is down from 7kb originally.

That is amazing. Nice work!

Opened 📌 [meta] Olivero page weight improvements Active for some similar issues in Olivero and added a couple more child issues here.