Front-end theme styles can bleed into Navigation

We saw this in the wild on the Mukurtu distribution. It's an open source Drupal install profile (which you can set up quite easily!):

I added quick implementation of
https://web.dev/articles/declarative-shadow-dom
Almost current Drupal browserslist https://caniuse.com/declarative-shadow-dom

Works as a charm. Toolbar button fixed ;)

CSS layers won't work because all declared layers will be less specific than styles with no declared layer (which is the rest of Drupal).

Web components would be ideal, because encapsulation is one of the main benefits. Not sure of @finnsky’s MR is enough though, as far as I can tell it just protects the button. It should also protect everything else there (list styles etc). From the Slack thread at https://drupal.slack.com/archives/C7AB68LJV/p1741201924377989, @m4olivei found issues with BigPipe and declarative shadow DOM not being compatible.

The additional specificity of the ID selector (like we did in offcanvas) is a great solution that would be relatively easy to apply if we can't get the web component method working.

We experienced something similar while integrating Navigation in one of our sites.

There was a global rule to apply specific styles to all the buttons across the whole site that cause conflicts with Navigation.

As reference, this is the diff that made the trick in that project:

-button,
+/* Apply button styles in layout container to avoid global overrides */
+.layout-container:where(button),
 [type="submit"] {
...

Changing tags per Issue tags field → and Issue tags -- special tags →

Hi,

I have added a font-family: inherit

Coming from https://drupal.slack.com/archives/C7AB68LJV/p1750418950750889

Had a long discussion about how to proceed with this at https://drupal.slack.com/archives/C7AB68LJV/p1751487654599299

Involved were navigation maintainers @nod_ and @finnsky (among others).

Per @nod_, we're going to move forward with the reset similar to how the offcanvas does it. We should also look at the fence created by https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/ckedi... and see if this is something we need or could use.

mherchel → changed the visibility of the branch 3511280-front-end-theme-styles to hidden.

New MR created with a "regular" CSS reset.

The "Donut" selector that @nod_ mentioned in Slack isn't necessary.

Because [data-drupal-admin-styles] exists multiple times on each page, we can't use a regular #id selector reset like we do we the off-canvas. Fortunately, there's a "quirk" with the CSS :is() pseudo-class, where its weight is equal to the highest weight selector in the list.

So, if we write :is(#extra-specificity, [data-drupal-admin-styles]), the ruleset will match [data-drupal-admin-styles], but have the specificity of the ID #extra-specificity. This is how we're proceeding.

This should be ready to go!

FYI, test is red because evidently the performance test counts the number of CSS bytes (which is obviously increasing with this MR).

This will need to be changed at https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/navig..., although I don't want to do it just yet, as reviews might necessitate further changes.

Let's leave this task for a quick fix, and continue experimenting with web components here
https://www.drupal.org/project/drupal/issues/3534298 ✨ Web component toolbar button Active

@mherchel

I found bugs in Tugboat:

1. on small screens: https://gyazo.com/d5ff663b2f211157fd129d687be2dd51
2. seems link toolbar-button has extra padding, at least size is different.

Good catch!

I found bugs in Tugboat:

Bugs fixed (🤞)