Off-canvas style resets are overriding styles (especially SVGs) resulting in display issues

Marked #3020542: Layout SVG's preview icons broken on Safari and #3022571: Layout SVG icons are not visible in Safari as duplicates

You should delete this whole rule set. Safari is the only browser actually evaluating these selectors. The other browsers do not understand a complex selector inside of :not() like :not(svg *) so they are not evaluating any of the selectors in the set.

@jmuzz

You are correct and as per the analysis, I have also found the same. I have removed the whole rule set as per your suggestion.

Please verify this patch and share your feedback.

Ran into this as well. Note that stable theme has this CSS copied into it as well, but I guess we are not allowed to change that?

Here is a patch that also removes the code from stable. Again, not sure on the rules surrounding that. Maybe that's not allowed?

#13 worked for us using core 8.7.4 and using a number of third party modules that had large images creating overflow offscreen in Safari.

I noted these issues in a related thread (which now may be closed in favor of this one since you have a patch): https://www.drupal.org/project/foundation_layouts/issues/3037557#comment...

But yes, I can verify that the "not" selectors were written incorrectly (they should be chained together, not in two different declarations), but am wholly in favor of removing them completely as "all: initial" is a bludgeon. Working through this in a current project, we will try this patch and verify. Thanks for all your work here.

This patch worked for me on a current Layout Builder project. Much, much better in Safari (v12.1.1 OSX 10.13.6). Drupal 8.7 project with the following dependencies in our Composer:

"composer/installers": "^1.5",
"cweagans/composer-patches": "^1.6",
"drupal-composer/drupal-scaffold": "^2.4",
"drupal-composer/preserve-paths": "^0.1.4",
"drupal/admin_toolbar": "^1.23",
"drupal/adminimal_admin_toolbar": "^1.9",
"drupal/adminimal_theme": "^1.4",
"drupal/animated_gif": "^1.1",
"drupal/backup_migrate": "4.x-dev",
"drupal/block_style_plugins": "2.x-dev",
"drupal/coder": "^8.2",
"drupal/coffee": "^1.0",
"drupal/config_installer": "^1.8",
"drupal/config_split": "^1.3",
"drupal/core": "^8.7",
"drupal/devel": "^1.2",
"drupal/draggableviews": "1.x-dev",
"drupal/entity_embed": "^1.0",
"drupal/entity_pager": "^1.0@beta",
"drupal/field_group": "3.0-rc1",
"drupal/focal_point": "^1.0",
"drupal/font_resize": "1.x-dev",
"drupal/honeypot": "^1.27",
"drupal/layout_builder_modal": "^1.0@alpha",
"drupal/layout_builder_restrictions": "^2.1",
"drupal/machine_name_widget": "^1.0",
"drupal/media_entity_browser": "^2.0",
"drupal/metatag": "^1.8",
"drupal/pathauto": "^1.3",
"drupal/recreate_block_content": "^2.0",
"drupal/responsive_favicons": "^1.5",
"drupal/role_delegation": "^1.0",
"drupal/scroll_progress": "^2.1",
"drupal/seckit": "^1.0",
"drupal/shield": "^1.2",
"drupal/token_filter": "^1.1",
"drupal/twig_field_value": "^1.2",
"drupal/view_unpublished": "1.x-dev",
"drush/drush": "^9.2",
"oomphinc/composer-installers-extender": "^1.1",
"zaporylie/composer-drupal-optimizations": "^1.0"

I found a similar issue here: #3043540: Off-canvas styling for autocomplete search results make them difficult to read
Perhaps close that as duplicate and merge the case in here?

By the way, shouldn't we perhaps discuss the whole ID selector logic and dark background?
Wouldn't it perhaps make sense that if Drupal is "light color" based by default, to make the off-canvas grey instead of fixing a lot of single problems with the dark background? Also keeping an eye on accessibility... just my two cents.

Of course that should be a separate (META) issue.

I tested #13 patch on our project and it works. Thank you.

Marked #3189524: Firefox 84+ has CSS issues for layout builder as a duplicate, but now this isn't just Safari

I can confirm that the patch in #13 does fix the issue I'm seeing in Firefox 84+

The patch in #13 does fix the issue on Firefox 84.0.1. Thanks!

Tested both Safari and FF and works as intended. The use of all is super heavy-handed in any core situation IMO.

Re-uploading patch #13, so it gets re-tested every to days against 9.2.x-dev.

At the moment the 2-daily retest is against 8.8.x-dev

For folks coming here who would prefer to avoid patching core until this is resolved, the same outcome can be achieved by using a libraries-override technique in your active theme, in the info.yml file, like so:

libraries-override:
  core/drupal.dialog.off_canvas:
    css:
      base:
        /core/themes/stable/css/core/dialog/off-canvas.reset.css: css/off-canvas.reset.css

Then put the "fixed" CSS shown in the patches above in your active theme at css/off-canvas.reset.css

@mark_fullmer -- this is fantastic! Thanks for reminding us of a far more elegant (and correct!) way of handling this.

Do you know if we need to include both the reset for
/core/themes/stable/css/core/dialog/off-canvas.reset.css

as well as
/core/misc/dialog/off-canvas.reset.css.

Both are mentioned in the patch.

Thanks again for your help!

Do you know if we need to include both the reset for
/core/themes/stable/css/core/dialog/off-canvas.reset.css

as well as
/core/misc/dialog/off-canvas.reset.css.

Only the reset for the CSS file in Stable is needed (presuming you are using a theme based on stable), since Stable does its own library override of the original file: https://git.drupalcode.org/project/drupal/-/blob/9.2.x/core/themes/stabl...

This is what is meant in https://www.drupal.org/docs/theming-drupal/adding-stylesheets-css-and-ja... with the words "full path to the most recent override of that library."

Thank you!

Random fail, back to RTBC.

IMO this might even be "major" because the off canvas layout builder is almost unusable in Firefox and Safari without this patch.

Seems I'm having the same problem (D9.1.2) at least with the SVGs, and also the font reset looks very weird, fieldset caption and detail summary formatting looks broken. Also supposedly collapsed fieldset are not collapsed etc.

It's worth mentioning that I see the display issues also appear on latest MS Chromium Edge on Windows 10.

Are the reset instructions new? Because that display problem wasn't apprent few days ago, but could be that I missed some updating progress on my local environment.

Long story short, patch from #30 solved this problem for me.

#30 seems to be working good for me as well.

I might be wrong, but isn't the way to handle multiple selectors with :not() to do something like #drupal-off-canvas *:not(div):not(svg *) or #drupal-off-canvas *:not(div, svg *), otherwise the #drupal-off-canvas *:not(svg *) line immediately includes all div's again?

ref: https://developer.mozilla.org/en-US/docs/Web/CSS/:not

Re #39 there is still the issue that :not(svg *) is considered a complex selector and only supported in Safari and Firefox 84+, which is where this bug seems to come from. As per the Mozilla link "The ability to list more than one selector is experimental and not yet widely supported" and see also https://caniuse.com/css-not-sel-list

I also wondered why Chromium Edge was now seeing this bug as noted in #37. The original Chromium feature request https://bugs.chromium.org/p/chromium/issues/detail?id=580628 led me to https://bugs.chromium.org/p/chromium/issues/detail?id=1139865 which suggests this CSS feature landed in Chromium in November 2020 and is presumably coming to a stable Chrome soon as well.

@longwave, ah that makes sense re: the complex selector!

Re: #37 We just started seeing this problem on Chrome, Firefox, and Safari today; wasn't an issue a few days ago for us either. Interestingly enough, my outdated Firefox 82.0 on my other laptop doesn't seem to experience this bug.

Did some git archaeology to help reviewers. I think we need to ascertain if this reset is doing anything useful at all before removing. The reset was added in #2826722: Add a 'fence' around settings tray with aggressive CSS reset. and then the SVG part was added in #2907420: The Off-Canvas CSS reset prevents SVGs from displaying. Specifically #drupal-off-canvas *:not(div), was added as a result of #2826722-43: Add a 'fence' around settings tray with aggressive CSS reset. so we need to repeat the earlier testing that lead to suggesting and implementing this fix.

Started to get the issues this week
In Drupal 8.9.x and Drupal 9.1.x
Looks like a Browser changes
as in #41

Updating Browsers will bring up the issue
After they added the features

Started seeing this issue today as well.

Tested patch #30
Thank you for the quick fix

This issue affects all old active and new built or demoing Drupal core websites.
With Layout Builder or any off-canvas used components in contrib or custom modules.

It fixes the issue in Drupal 8.9.x and Drupal 9.1.x

Not sure we should change to Reviewed & tested by the community yet.
More testing should follow for sure

Hoping to manage a fix in the current or next Drupal releases

patch #30 work for me as well.

Suddenly had this bug with Chrome.
Using Drupal 8.9.11(production) and 8.9.13 (test) with bootstrap_layout_builder 2.0.1

Fixed with #30 as well. Thanks

I suspect this will soon be a universal problem, if it isn't already, based on this Tweet I came across: https://twitter.com/LeaVerou/status/1354760561087676416

(as I understand that the current core code works when complex selectors *aren't* supported)

Also seeing this now across all browsers. The overrides also broke a layout plugin colorpicker we implemented. The patch in #13 and #30 fixes this for us as well.

I experience this issue in Chrome and Edge. I'm a newbie Drupal user, so I've been going crazy over this issue for the past week. I've tried installations on of a number of BS3 distros, recommended official distro, etc. I've tried building sites on Linux Mint, Ubuntu VMs, in Docker containers on Windows 10. I tried accessing these sites using different computers. Each time same result. In each case Layout Builder side panel with icons and options looks messed up. I really thought that I'm not understanding at all how to achieve a basic functionality out of Drupal if I couldn't even get installation done correctly.

I even tried a fresh basic default install of official latest distro with just Umami demo enabled. Even then I got this same exact issue with the Layout Builder. I finally went through CSS because I couldn't find whether this was a known issue or really was a problem with my inability to do a basic Drupal install. Anyhow, once "all: initial;" was checked off the side panel of Layout Builder started to look just like in demos all across the web.

This is definitely a real issue, and if it is known, and there's a work-around then it should be mentioned very clearly on the latest distro download page.

I wasn't seeing this issue on Chrome version 87.0.4280.141, but I see it after updating to 88.0.4324.96.

The patch from #30 works for me!

Closed #3196143: Settings tray styles broken due to off-canvas.reset.css as duplicate, noting this here as it is an extremely detailed bug report with similar findings to what has been discovered here.

Also removing the list of browsers from the issue title, now Chrome 88 is affected all major browsers are suffering from this bug.

Here's a set of instructions for newbies like me to get this issue fixed in production. Following these instructions will apply the patch mentioned in post #30 of this thread directly to your production server. You need to have ssh access to your server, and have composer utility available to you on that server.

1. access your server using ssh
2. navigate to the folder just above "docroot" folder of your drupal website. This is where you will find existing file named composer.json
3. open "composer.json" file in a text editor (i.e. sudo nano composer.json)
4. inside section "extra" add a new block of code (add a comma after last block before you insert new block "patches"):

    "patches": {
        "drupal/core": {
            "Off-canvas style resets": https://www.drupal.org/files/issues/2021-01-06/off-canvas-style-resets-2958588-13.patch
        }
     }

5. save file and exit
6. run command: composer install
7. run command: composer update --lock

that's it.

Instructions were figured out thanks to this post: https://www.drupal.org/forum/support/module-development-and-code-questio...

If these instructions can be improved/corrected then please help out. Thanks!

Re #43 I am not sure exactly what tests need to be repeated here, nor is it clear to me from the original comments what that was trying to solve. I think that fixing this now-critical bug (as it affects all major browsers) is preferable to looking for an edge case that may or may not still exist and we can deal with any fallout from or tweaks to this fix in a followup.

This patch is #30 with the same removed from stable9 for use in 9.x. #30 can be committed to 8.9.x.

As far as layout builder is concerned, currently in Seven the off-canvas dialog with SVGs looks horribly broken:

Safari 14:

Firefox 84:

Chrome 88:

After applying the attached patch:

Safari 14:

Firefox 84:

Chrome 88:

Note that the misaligned pencil icon is a separate issue and that should be done in a followup if it doesn't already exist.

Further before and after screenshots, all in Firefox 84:

Before:

After:

While I was bumbling around researching #3196143: Settings tray styles broken due to off-canvas.reset.css, I stumbled on an article by Andy Clarke where he found that :not() doesn't work in multiple, comma-separated selectors (see "Bad Magic" heading near the end of Using multiple :not() selectors). He recommended chaining at the time (e.g. "*:not(.foo):not(.bar)) but that didn't seem to work well for this issue.

Given that most current browser versions now support multiple argument lists and complex selectors for :not() — or soon will — I decided to try that instead. So:

#drupal-off-canvas *:not(div),
#drupal-off-canvas *:not(svg *)

Becomes:

#drupal-off-canvas *:not(div, svg *)

That seemed to work well in the current version of every browser I tested (Chrome, Firefox, Edge, Safari, even IE 11!). I'm not sure it's the right solution, but, given the concerns raised in #43, it might be worth testing as a possible alternative to entirely removing the rule.

#57: that is a good point, but one thing I don't get is why does it work in IE 11?

https://caniuse.com/css-not-sel-list shows that complex :not() is only supported by 19.45% at present. Is it just that in the browsers without support, the rule is being ignored entirely? And if the rule is ignored entirely, and the off-canvas tray is working just as well without it, should we just remove the rule?

I'm tagging this for accessibility because of the low color contrast in the section layout selection page. I've been updating sites all day to remediate this issue on U.S. Govt. websites because of that.

I'm choosing not to mark it as RTBC because I don't know if removing all of the styles might have unintended consequences. For what it's worth, I overrode the stylesheet and only removed the all: initial; property. Doing that solved the problem well enough for us.

Re #58: Yeah, I think you're right. I did some more testing and he newer syntax I mentioned

#drupal-off-canvas *:not(div, svg *)

appears to only partially work in that <div>s are excluded as desired, but 'svg *' doesn't seem to do anything at all. So it's not really a viable solution. I'm guessing IE just ignores all of it (which is why it seems to work there?).

Thank you, Dave for #55

Needed for when the Layout Builder was released in Drupal core in a number of older versions too.

Is it right to have Browser version media selections or an extra library switcher for old and new browsers?

Like @supports or not supported

Patch #30 with the help of #54 worked for me.
Running 8.8.11
Thanks!

I can confirm patch #30 seems to work - we're running 8.9.13.

I'm in agreement with #55 - this issue can make Layout Builder a hard sell in today's competitive market.

Thanks!

#13 worked for me using 8.9.13 (guess it's same as #30) and now I find I have to make this patch in all my sites using LB as all are having this issue. I use Chrome.

I think this should be considered as critical and get committed 'cos it would be giving lots of people a bad experience with LB.

off-canvas-style-resets-2958588-13.patch: Tested in 9.1.4 core with Google Chrome Versión 88.0.4324.150

Works great.

I can't imagine what unintended consequence would be worse than the whole sidebar being broken.

I don't think it's feasible to remove the fence altogether because that increases the chance of styles leaking to the off-canvas. For example, I tested this using Layout Builder and Claro and I can see that the Claro form styles are leaking to the off-canvas after this change:

Here's how that looks before the patch:

Solved by commenting out all: initial at

#drupal-off-canvas *:not(div), #drupal-off-canvas *:not(svg *), #drupal-off-canvas *:after, #drupal-off-canvas *:before {
    /* all: initial; */
    box-sizing: border-box;
    text-shadow: none;
    -webkit-font-smoothing: antialiased;
    -webkit-tap-highlight-color: initial;

Screenshots attached.
OS: Windows 10 Google Chrome: Version 88.0.4324.190 (Official Build) (64-bit)
Drupal: 8.9.13 and 9.1.4 (Having this issue in both)

Re-showing most recent patch that was most likely accidentally hidden by Blackstallion

The concern raised in #67 seems moot (for now); the off-canvas styling in question wasn't even being applied in the last "known-good" versions of browsers.

I vote we just remove it until a decision can be reached about the proper way to handle the styling reset that #2826722: Add a 'fence' around settings tray with aggressive CSS reset. was trying to address; I'd much rather have this working the way that it was previously (i.e., without the broken styling reset) than have it in its current broken state.

RTBC +1 #55 and hard agree with #66.

#31 worked for me with this code in my info.yml file. Thx!

libraries-override:
    core/drupal.dialog.off_canvas:
      css:
        base:
          misc/dialog/off-canvas.reset.css: css/theme/off-canvas.reset.css

Resetting status per the review from the front-end framework manager in #67. I'm not sure what you mean in #70 about it being moot, @lauriii attached screenshots that show a regression.

Maybe we'll end up going forward with this as-is, but it's worth discussion.

I noticed the same style bleeding from Claro into the off-canvas sidebar as #67's screenshot, but in an older version of Chrome (prior to Version 88.0.4324.96) without any of the patches from this issue (I wanted to see what the off-canvas sidebar was meant to look like).

Perhaps that is what #70 is referring to by the following statement; that the fence wasn't preventing style leakage in older/"last known-good" browsers as intended?

the off-canvas styling in question wasn't even being applied in the last "known-good" versions of browsers

To reproduce:

1. Follow these instructions from the Chromium Project to grab an older version in which the off-canvas sidebar looked not broken (e.g., Version 87.0.4280.0 in my case)
2. Spin up a sandbox on simplytest.me
3. Enable Layout Builder and Layout Discovery
4. Go to /admin/structure/types/manage/page/display/default and check the box Use Layout Builder
5. Click Manage Layout button
6. Click Add block in a section
7. Make note of the appearance of the off-canvas sidebar
8. Go to /admin/appearance and install Claro and set Claro to the default theme
9. Go back to /admin/structure/types/manage/page/display/default/layout and click Add block in a section
10. Make note of the appearance of the off-canvas sidebar

In step 7, the off-canvas sidebar looked as anticipated (see screenshot 1) whereas in step 10 the styling from Claro bleeds into the off-canvas sidebar (see screenshot 2).

Screenshot 1:

Screenshot 2:

I haven't gotten a chance yet to figure out how to get old versions of Firefox/Safari/IE yet and repeat these steps there, but figured maybe this information might help add to the discussion regarding the fence?

@tim.plunkett

#74 is exactly right; the leaks from Claro were always happening, even after #2826722: Add a 'fence' around settings tray with aggressive CSS reset. was committed. This is because browsers were ignoring the style reset introduced in that issue. Had browsers actually been applying the styles introduced in that issue at the time, it would have never been committed as-is because the proposed style reset was arguably bad code.

Now that browsers are paying attention to the style reset introduced in that issue, Layout Builder is practically unusable in updated browsers. The style reset introduced in #2826722: Add a 'fence' around settings tray with aggressive CSS reset. is the root cause of the regression described by this issue; it should be reverted so that we're not busy engaging in a philosophical discussion while Layout Builder remains broken.

Waiting for a perfect solution, in this case, is definitely the enemy of the good.

I tried to come up with a solution that would allow us to retain the CSS reset and fix the bug. I could use some help on testing this approach manually.

Rerolled to latest 9.2.x.

Tested the patch from #77 in Chrome Version 88.0.4324.192.

Definitely looks much better now, yay! However, a couple of minor things I noticed:

• The cursor isn't a pointer hovering over links (unfortunately I couldn't capture this in my screenshots :( ). This was evident with both Bartik and Claro as the default theme.
• When the default theme was set to Claro, the dropdown arrow on the block categories was missing. Compare Screenshot 2 to Screenshot 5 (very minor, but figured I'd mention).
• There is some slight styling leakage from Claro with regards to input sizing and some input positioning (e.g., the checkbox and dropdown select list on the Body field block in Screenshot 3 compared to Screenshot 6).

Again, these are probably pretty minor and probably aren't showstoppers for getting some sort of fix in so Layout Builder is usable for folks, but figured these were worth noting.

My testing steps, for anyone else who has availability to test in IE/Firefox/Safari:

1. Spin up a sandbox on simplytest.me on 9.2.x with the patch from #77
2. Enable Layout Builder and Layout Discovery
3. Go to /admin/structure/types/manage/page/display/default and check the box Use Layout Builder
4. Click Manage Layout button
5. Click Add section
6. Make note of the appearance of the off-canvas sidebar
7. Click Add block in your new section
8. Make note of the appearance of the off-canvas sidebar
9. Go to /admin/appearance and install Claro and set Claro to the default theme
10. Go back to /admin/structure/types/manage/page/display/default/layout and click Add section
11. Click Add block in your new section
12. Make note of the appearance of the off-canvas sidebar

Screenshot 1:

Screenshot 2:

Screenshot 3:

Screenshot 4:

Screenshot 5:

Screenshot 6:

Oh, one more note from testing #77: it doesn't look like there is a visual indicator for required fields in the off-canvas sidebar (at lease in Chrome Version 88.0.4324.192). The title field is required, but there isn't the little red asterisk next to it to signify that it is required. See screenshot below:

This might be unrelated to this issue though; I think I noticed its absence several months ago on a project.

Thank you for the extremely thorough manual testing and documenting the steps used for testing! That is very helpful! 💯

This should address #78.1. Unfortunately I was unable to create interdiff because git is going haywire with the file copies.

The issues with Claro styles leaking are pre-existing. We should look into those in a separate issue.

I also tested #79 manually and it also seems like a pre-existing problem which should receive it's own issue.

The previous patch is going to fail stylelint 🤦‍♂️

Tested the patch from #81 in Chrome 89.0.4389.82, Safari 14.0.3, and Firefox 86.0 (64-bit).

Looks good!!! 🙂I've attached screenshots in case anyone wants to verify or noticed something off. Only note is in Firefox: in my last screenshot, the select list dropdown arrows seem a bit misshapen from bleeding from Claro (but again, makes more sense for a followup).

Still need someone to test in Microsoft Edge and/or Internet Explorer.

My testing steps, for anyone else who has availability to test in Microsoft Edge and/or Internet Explorer:

1. Spin up a sandbox on simplytest.me on 9.2.x with the patch from #81
2. Enable Layout Builder and Layout Discovery
3. Go to /admin/structure/types/manage/page/display/default and check the box Use Layout Builder
4. Click Manage Layout button
5. Click Add section
6. Make note of the appearance of the off-canvas sidebar
7. Click Add block in your new section
8. Make note of the appearance of the off-canvas sidebar
9. Go to /admin/appearance and install Claro and set Claro to the default theme
10. Go back to /admin/structure/types/manage/page/display/default/layout and click Add section
11. Click Add block in your new section
12. Make note of the appearance of the off-canvas sidebar
13. Repeat Steps 4-12 for the latest versions of each browser.

Attaching screenshots as per #82 for Edge 89 / IE 11.

I think we'll probably need to work something out for the select box styling because of possible A11Y concerns. Settings to Needs Work for this.

@clayfreeman, yay thank you for testing in Edge 89 / IE 11! 🎉

Just to make sure I'm not misunderstanding, when you said the following in #83:

I think we'll probably need to work something out for the select box styling because of possible A11Y concerns

You are referring to the select box styling issue in the screenshot of IE 11 and Claro (specifically https://www.drupal.org/files/issues/2021-03-09/IE%2011%20-%20Claro%20-%20Block%20Options.png), right?

Other than that issue, so far it looks pretty good in Edge 89 / IE 11!

That is correct - I don't see how we'd get A11Y sign-off without an indicator on select boxes.

I tried the patch on #81 but it failed since I am on Drupal core 8.9. Is there a version that isn't for D9 yet?

Rerolled.

Rerolled again? Sorry, I'm new to working with the PostCSS-based codebase.

Tried to reroll against 8.9.x
My first time rolling a patch that modifies .css

@clayfreeman -- figured out what's causing the select arrows to disappear when using Claro: it's this line here in Claro.

I'm wondering if adding the following to /core/misc/dialog/off-canvas.base.pcss.css, core/themes/stable/css/core/dialog/off-canvas.base.pcss.css, and core/themes/stable9/css/core/dialog/off-canvas.base.pcss.css might be a good safeguard in case other contrib themes do the same?

#drupal-off-canvas select::-ms-expand {
  display: block;
}

My attempt to re-roll the patch from #81 for 9.2.x with the suggestion from #90 for select buttons in IE.

Unfortunately having a bit of a rough time getting started out with PostCSS and my git diff is going haywire as well, so I'm hoping this patch has everything from #81.

Here are two re-rolls of #91, but for 8.9.x.

The first patch includes the respective CSS and the .stylelintignore changes without PostCSS, and the second patch includes those changes with PostCSS (I was not sure if we are using PostCSS in 8.9.x, hence creating both patches just in case).

I haven't manually tested either of these yet.

Realized one of the files in #92 was missing a couple of styles 🤦‍♀️

Anywho, re-rolled for 8.9.x -- first one is without the .pcss.css files, and the second one includes .pcss.css files.

I think we should address the bug with the Claro select element in a follow-up issue: #3204104: Claro styles leaking to off-canvas.

In that case, RTBC for #81 from me.

One small docs request before that (and an issue summary update), but otherwise I agree on RTBC.

Also from now until this is committed, please stop posting 8.9 backports. It will only confuse the testbot.

1. +++ b/core/misc/dialog/off-canvas.base.pcss.css
   @@ -4,16 +4,101 @@
   +#drupal-off-canvas {
   

   This is a long list of elements. Can a comment here mention which ones are excluded from the list? (div and span, from what I can see)

2. +++ b/core/themes/stable/css/core/dialog/off-canvas.base.css
   @@ -44,87 +140,105 @@
   -  margin: 10px 0;
   +  margin: 0.625rem 0;
   

   Are all these changes because of a change to our compiling rules? Or were they manual changes from another issue incorrectly made to the generated CSS that need to be reflected in the pcss?

Added comment. I had to double check the list again to remember all elements that I had excluded and I noticed I had missed few elements that probably should be on the list. Here's an updated patch with those elements added, as well as comment explaining where the list of elements has been taken and which elements were excluded.

The changes from px to rem are caused by PostCSS px to rem plugin which we have enabled #3117698: Allow PostCSS Plugin “Px to Rem” in core for Olivero theme.

Working on updating the manual testing screenshots. Will update soon.

Here's a ZIP file of all the browsers' screenshots. I'll note that there doesn't appear to be any regression & there was actually an improvement: #85 is fixed!

Pending testbot, this is RTBC from me.

FWIW, if you're needing to quick-fix this right now, the patch in #13 does not include the Stable9 theme, and won't work for any themes using that as a base theme. Also note the most recent patch at #97 will not apply to 9.1.x. The best approach in this case will be to apply the libraries-override fix as per #31, but use /core/themes/stable9/css/core/dialog/off-canvas.reset.css as the overridden path.

We still need an issue summary update as per #96. I was wondering if we needed a change record but I've checked Bootstrap and a few other usual candidates and no one is overriding the core implementation so I don't think a CR is necessary.

The implementation does have a slight change on the weight because we're changing from asterisk to a specific elements. The use cases that I could think of where this could cause issues are if someone is providing off-canvas specific CSS targeting element types and it's loaded before the reset, and also if someone is doing off-canvas specific reset overrides using an asterisk as a selector. These both seem rare edge cases so it would probably be just noise to post a CR for this.

Not sure if one example merits a CR, but Bootstrap Styles comes to mind as a project that does extensive off-canvas styling. Seems like their light and dark theme css both do some off-canvas reset overriding, around line 1147 e.g.:

#drupal-off-canvas *,
#drupal-off-canvas *:not(div) {
  color: #383A40;
  background: unset;
  font-family: inherit;
}

Working on updating issue credit. In addition to people already creditted:

• Credited @galactus86 for supplying a patch
• Credited @tim.plunkett, @justcaldwell for reviews
• Credited @mark_fullmer for supplying a useful workaround

I actually found out that CSS is smart and adds weight for the element type even though it's defined in :not(). Therefore, the current solution doesn't change the weight at all. Here's an excellent blog post about this: https://bitsofco.de/on-not-and-specificity/.

I also tested Bootstrap Styles manually to confirm that this change doesn't have an impact at least on the rule mentioned in #104.

Committed and pushed 2fccc04de4 to 9.2.x and 7e6c791fdd to 9.1.x. Thanks!

I think we should consider backporting this to 8.9.x

Here's my attempt at a backport patch to Drupal 8.

The 8.9.x backport LGTM. Tested in Chrome, Firefox, Edge, and IE 11.

@clayfreeman I am on 8.9.13 and tried applying patch #110, but it could not apply patch. I've no idea how to tell what the problem was, because it just restates that in the exception. I'm not a developer. I just pretend to be one for my library. I could have missed something important, but I've successfully installed module patches using Composer, so I pretty much followed the same process for this.

Just noting that I'm on Drupal 9.1 and the patch from #93 worked for me.

I'm on 8.9.13 and trying to implement the libraries override method in #31. However, the override stylesheet fails to load. I've verified that the stylesheet is reachable in its expected location /themes/custom/utni/dist/css/off-canvas.reset.css and that the Drupal cache has been cleared -- to no avail. Other overrides, such as system/base, do function as expected.

libraries-override:
  system/base: false
  views/views.module: false
  core/drupal.dialog.off_canvas:
    css:
      base:
        /core/themes/stable/css/core/dialog/off-canvas.reset.css: dist/css/off-canvas.reset.css

Am I overlooking something obvious?

@C. S. Comfort - is your theme using stable as a base theme? If not then the override would be:

libraries-override:
  system/base: false
  views/views.module: false
  core/drupal.dialog.off_canvas:
    css:
      base:
        /core/misc/dialog/off-canvas.reset.css: dist/css/off-canvas.reset.css

I think...

An alternative solution would be to use composer-patches and apply the patch in #110.

+1 for the 8.9.x backport in #110

Tested #110 manually on Simplytest.me and it seemed to work as expected. +1 for backport.

Committed e2e6d50 and pushed to 8.9.x. Thanks!

Just updated from 9.1.5 to 9.1.7 and had been using the patch in #13. After updating to 9.1.7 I assumed the patch was not necessary so I removed it - but the issue came back. It makes using Layout Builder for our clients pretty frustrating.

We are using Bootstrap Layout Builder with a Bootstrap 4 subtheme.

Tried patches 13, 81 and 97 and all fail to apply.

I was successful in using the libraries-override as per Mark Fullmer in #31 and that cleared up the issue.

We updated to 8.9.14 thinking this would be fixed, but there was no visible change when I went to use Layout Builder on a page. I'm not a developer, so I may have misunderstood. Do we have to change to a different 8.9? Thanks!

Per #123, 8.9.14 looks to only contain the security fix per the release notes.

This is a relatively big change that shouldn't break anything, but is worth calling out for custom themes.
Reopening for a change record and a release note snippet.

We have a ticket to track the impact of the latest changes and apply it to Bootstrap Layout Builder:
https://www.drupal.org/project/bootstrap_styles/issues/3211154

Attempt to re-rolled 110 against latest 8.9.x branch

I see that this was committed already.

#127 does not apply cleanly, and appears to be a diff between another patch, given the file size discrepancy between itself and #2958588-110: Off-canvas style resets are overriding styles (especially SVGs) resulting in display issues.

Per #130, this doesn't need a reroll for the latest 8.9.x release, thank you for the quick response!

There is no reroll needed, this was already committed to 8.9.x in #121.

This issue is only "needs work" for the change record and release note.

CR added here: https://www.drupal.org/node/3212880

Release note snippet below:

Prior to this release, off-canvas styles were reset by using an asterisk CSS selector and excluding elements that shouldn't be targeted by using a negation selector. The strategy in this release has changed such that all elements that need to be targeted are explicitly listed instead of using an asterisk selector. See this change record for more information: https://www.drupal.org/node/3212880

CR added here: https://www.drupal.org/node/3212880

Any reason it's not published yet?

Published the change record.

Having issues in Drupal 9.2.x.

A few days ago, we have upgraded to 9.2.x and non of the patches were successfully applied. But following Mark Fullmer's suggestion in #32, I was able to temporary have a solution till a patch for 9.2.x actually comes out.

Or maybe this solution is good enough till core has an update.

@bowiechang the patch for this issue has already been merged into 9.1 and 9.2, so you no longer need to use a patch.

Doing some shenanigans with Sortable js + off_canvas, and that all: initial makes it impossible to drag from off_canvas

FYI: Added a feature-request to provide a class to opt-out from reset in contrib, if needed: https://www.drupal.org/project/drupal/issues/3395617