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.csssources and the compiled.cssfiles. - 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
Issue fork drupal-3621155
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
Comment #3
f0ns commentedComment #4
jurgenhaasThank 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?
Comment #5
f0ns commentedHad 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.
Comment #6
jurgenhaasI just opened issues in their queues, and left it open to them, whether they want to take it over or not.
Comment #7
f0ns commentedOh, thanks for your help!
Comment #8
f0ns commentedBump! would be nice to get this cleanup in.
Comment #9
jurgenhaasThank 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:
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.