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.

@bnjmnm thank you!

FYI: Guess I'm not the right one to implement and decide on this, as I'm not really experienced in frontend ;) My times writing bit more complex CSS are a decade ago, so please don't wait for my unqualified feedback here. I'll watch this issue and had the idea for this, yes, but my focus is elsewhere. Hopefully we have some frontend / CSS guys to take a look :)

Thank you all, I'm really happy you like the idea!

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

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.