Problem/Motivation

The Admin theme (default_admin) contains CSS selectors that only ever match markup provided by contrib modules. core/themes/default_admin/css/components/tabledrag.pcss.css (and its compiled tabledrag.css) styles .field--widget-entity-reference-paragraphs, which is provided by the contrib Paragraphs module.

These are leftovers from Gin's time in contrib. As stated in #3619804-12, support for contrib modules should not live in core — it is up to contrib modules to provide their own styles.

Proposed resolution

Remove contrib-specific selectors from the Admin theme's CSS, and audit the rest of the theme's stylesheets for similar cases.

Remaining tasks

  • Grep the theme's CSS for other contrib-only selectors.
  • Remove them from both the .pcss.css sources and the compiled .css files.
  • Review.

User interface changes

None in core. Sites using the affected contrib modules with the Admin theme may see minor styling differences until those modules ship their own styles.

API changes

None.

Data model changes

None.

Related issues

#3619804: Remove unused templates from the Admin theme

Issue fork drupal-3621155

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

f0ns created an issue. See original summary.

f0ns’s picture

Status: Active » Needs review
jurgenhaas’s picture

Thank you @f0ns for the next round of clean-up. These have been oversights from the last rounds of cleaning similar things up.

In previous rounds, we had informed the contrib module maintainers in issues about the removal so that they had a chance to know and to ideally incorporate them into their own module's css. I've looked through the MR and would say, we should probably do that again. It should be sufficient to link them to the MR where they can find what has been removed.

What do you think?

f0ns’s picture

Had not thought about that but it sounds like a sensible thing to do.

Did you use the issue queue before or how did you reach out (ex. Slack).

I'll try to do it in a similar way.

jurgenhaas’s picture

I just opened issues in their queues, and left it open to them, whether they want to take it over or not.

f0ns’s picture

Oh, thanks for your help!

f0ns’s picture

Bump! would be nice to get this cleanup in.

jurgenhaas’s picture

Thank you for the reminder @f0ns, this slipped through my radar.

The MR looks good to me and I've verified with an LLM that we really don't remove anything that's used elsewhere in core. And it's not, all signals are green.

However, the LLM found more that is not covered yet. I wonder if we want to extend the scope of this issue or move this to a follow-up:

  • update.pcss.css: .drupal-upgrade-status-summary-form, .upgrade-status-next-step-remove, .known-errors, .known-warnings, .no-known-error - Upgrade Status
  • status.pcss.css: .pb-actions, .pb-module-page__categories-list-item, .pb-project-categories__item, .project_status-indicator - Project Browser
  • description-toggle.pcss.css: .field-group-details, .field-group-fieldset - Field Group
  • layers.pcss.css: .my-workbench, .imageapi-optimize-default-pipeline, .winnow-input
  • edit-form.pcss.css: .redirect-table__path - Redirect
  • media-library.pcss.css: .dropzone-enable - DropzoneJS
  • button.pcss.css: .multiple-fields-remove-button; form.pcss.css: .horizontal-tab-button, .length-indicator
  • probable dead Gin leftovers: .admin--classic-toolbar, .admin--horizontal-toolbar, .admin--vertical-toolbar, html.admin-toolbar-expanded

Caveat: a zero hit is not proof for classes core builds dynamically (Html::getClass()), so each needs a one-line sanity check - but pb-*, upgrade-status-*, redirect-table__* are not core-generatable.

Also, if you opened issues with other projects, it would be great to link them here as related.