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.