Add a class to opt-out of off-canvas resets in contrib

Like the idea. Think a framework manager would have to make the call.

This solution is something I'd FEFM-approve some form of. Seems like a fairly gentle change that would address an annoying pain point with off canvas dialogs.

• This should include tests that use getComputedStyle to confirm styles are applied/not applied accordingly
• If we go with a long class name as suggested, they should be BEM. If the class name was shorter I'd be inclined let that BEM requirement slide. (In other words, if it's already unweildy, then BEM should be there.. but something easier to understand at a glance might be better DX than BEM.
• Is there any benefit in having two classes - one for a single element and another for .class * so all child elements are reset immune?
• I'd like to see a comment in the CSS explaining the use of the no-reset class(es). The ideal place would be where someone is most likely to look when they are frustrated and tracking down the CSS that is messing with their UI.

Thanks @bnjmnm! Removing the tag for frontend framework.

Just stumbled on this one when working on #3402171: Select2 css not applied inside off-canvas because Drupal core reset.css removes it (since Drupal core 10)

Does someone knows a workaround that can be used?
Maybe a method to replace core reset.css with an application specific one.

And imagine we have the exclusion class. How will the css of contrib look? Something like this:

button.contrib-module {border: 2px solid grey}
.drupal-off-canvas-wrapper-noreset button.contrib-module {border: 2px solid grey}

Wouldn't that mean that all contrib css that might be rendered inside the off-canvas must be duplicated with the exclusion class prefixed. 🤔

@ndf — yes, you can replace core's off-canvas reset with your own as a workaround:

use Drupal\Core\Asset\AttachedAssetsInterface;
...
function YOUR_MODULE_css_alter(&$css, AttachedAssetsInterface $assets) {
  if (isset($css['core/misc/dialog/off-canvas/css/reset.css'])) {
    $css['core/misc/dialog/off-canvas/css/reset.css']['data'] = 'path/to/your/module/css/your-module-off-canvas-reset.css';
  }
}

Then your-module-off-canvas-reset.css is just a copy of core's, with your selector added where needed:

#drupal-off-canvas-wrapper *:where(:not(svg, svg *, .ck-reset *, [data-drupal-ck-style-fence] *, .ui-resizable-handle, .YOUR-CLASS)) {
  all: revert;
  box-sizing: border-box;
  -webkit-font-smoothing: antialiased;
  line-height: 1.4;
}

#drupal-off-canvas-wrapper *:where(:not(svg, svg *, .ck-reset *, [data-drupal-ck-style-fence] *, .ui-resizable-handle, .YOUR-CLASS))::after,
#drupal-off-canvas-wrapper *:where(:not(svg, svg *, .ck-reset *, [data-drupal-ck-style-fence] *, .ui-resizable-handle, .YOUR-CLASS))::before {
  all: revert;
  box-sizing: border-box;
  -webkit-font-smoothing: antialiased;
}

Maybe not ideal, but it can make life much easier when you're trying to style for off-canvas.

Wouldn't that mean that all contrib css that might be rendered inside the off-canvas must be duplicated with the exclusion class prefixed.

Yes, I think so. That's why I'm hoping for a shorter classname, maybe something like .drupal-noreset.

Of course, if/when more projects take this approach, there will be conflicts.

Yes, I think so. That's why I'm hoping for a shorter classname, maybe something like .drupal-noreset.

I'm pro-BEM in many cases, but (as a front end framework manager / committer) I'm not opposed to approving something with a shorter classname. I think it's helpful to see at a glance if something has been un-reset and .drupal-off-canvas-wrapper-noreset is a little too long for it to register quickly.

For this to get further we'd need some kind of test coverage like what I requested in #6. If anyone following this issue is interested in doing this but unsure where to start (either writing the tests, or just getting it set up locally), find me on Drupal Slack and I can assist. This seems like a pain point worth solving sooner than later.

Does anyone have a workaround or solution to remove the reset.css, especially since it adds the nuclear "all: revert" and is injected into the DOM as an inline style?

There doesn't appear to be a way to override the css since one can't revert a revert.

I've also tried using the hook_css_alter() approach to remove the reset.css from the css array, but its contents get added and injected regardless.

Any help would be greatly appreciated.

Had to go crazy with !important tags to deal with the "all: revert". I know

The Settings Tray Module was approved for removal in #3576315: [policy, no patch] Move Settings Tray to a contributed project.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3576667: [meta] Tasks to deprecate Settings Tray and the removal work in #3581818: [meta] Tasks to remove Settings Tray module.

Settings Tray will be moved to a contributed project before Drupal 12.0.0 is released.