[Voltron patch] Move all remaining *.admin.theme.css to Seven

Vehicle Voltron or Lion Voltron? It matters.

For the front-end UI things, we should make sure we do the funky magic that lets those work on the frontend no matter the theme. This was the example you had mentioned LewisNyman.

<?php
/**
 * Implements hook_library_info_alter().
 *
 * Includes additional stylesheets defined by the admin theme to allow it to
 * customize the Node Preview bar appearance.
 *
 * An admin theme can specify CSS files to make the node preview bar match the
 * administration experience in the back-end.
 *
 * The CSS files can be specified via the "node_preview_stylesheets" property
 * in the .info.yml file:
 * @code
 * preview_stylesheets:
 *   - css/node-preview.css
 * @endcode
 */
function node_library_info_alter(&$libraries, $extension) {
  if ($extension === 'node' && isset($libraries['drupal.node.preview'])) {
    $theme = Drupal::config('system.theme')->get('admin');
    
// First let the base theme modify the library, then the actual theme.
    $alter_library = function(&$library, $theme) use (&$alter_library) {
      if (isset($theme) && $theme_path = drupal_get_path('theme', $theme)) {
        $info = system_get_info('theme', $theme);
        // Recurse to process base theme(s) first.
        if (isset($info['base theme'])) {
          $alter_library($library, $info['base theme']);
        }
        if (isset($info['node_preview_stylesheets'])) {
          foreach ($info['node_preview_stylesheets'] as $path) {
            // Ensure it overrides any styling from the frontend theme.
            $library['css']['theme']['/' . $theme_path . '/' . $path] = ['weight' => 20 ];
          }
        }
      }
    };
    
$alter_library($libraries['drupal.node.preview'], $theme);
  }
}
?>

I understand the positive things that this could give us. How much I would like to see this happen, I just feel like with the given time we it might be a bad idea to make it happen since I don't believe we could make it good enough. People writing their own admin themes (which is small number of people) would benefit out of this most because they can control the supported modules and frontend themes quite easily but giving that responsibility for contrib project seems really tough with the given artifacts. It would be also nice to find a solution that works everywhere the same way, not that every module implements its own way of managing this.

What happens if markup is modified for some reason in the frontend theme? Also in addition for the CSS and JS admin theme should be able to modify the markup, like the other systems implementing this kind of pattern. Now there is too many things to break your stuff. Someone might say there is already ways to break stuff - yes, there is but its somehow predictable and its happening in a sandbox - in the current theme tree. By making this change we would make frontend themes suffer one more unknown; how does admin theme modify my CSS and JS, what markup is required by it to work properly. TBH I believe some theme wouldn't be compatible with each other at all so there should be some way to define which projects are supported and which not to ensure high quality for users.

And how are we supporting contrib module projects by doing that? Lets say I create my own fancy admin menu module and there is multiple different designs for that, how am I supposed to be providing those with the new ideology? By creating multiple admin themes providing the styles or creating new modules for that? Also not many of the admin themes would be theming my contrib, so am I supposed to be able to find admin themes supporting that contrib? What if I use multiple modules and I cant find admin theme supporting them all and they are not compatible with each other?

I don't feel like all the possible use cases how frontend themes can be used has been seriously considered while making these decisions. I also don't think doing this last minute before RC1 is good idea because we cannot get feedback from the theme developers.

I'm really sorry to be against this and also raising my concerns here especially considering all the good things it could bring for us, but I don't feel confident for staying silent.

@laurri You worked on a strategy for addressing this, could you provide an update on this?

I added a suggestion for a possible solution in #2632584: Add a "public admin" theme subtype so that admin themes can have subthemes for front-end UI components.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Does not appear to be a core issue so moving to Seven.

I agree with comment #8. Furthermore, the links issues are marked outdated, needs work, or postponed; one of the issues is for the Claro theme.

Because this, I am going to close is issue as outdated.