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 (🤞)

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Conflicts fixed!

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

I'm not going to keep re-rolling this everytime some CSS changes. Let's get a review in before fixing the tests and recompiling the CSS.

The CSS is a bit beyond me, but in terms of testing this, here is before & after with Environment Indicator + Devel enabled for example. Thank you for your work on this!

Before (bleeding in as issue summary describes):

After (looks great):

Haven't tested the UI but I'm ok with the clever solution. Maybe we can name it #extra-specificity-hack? to make sure we're not saying it's a supported pattern, and as a callback to old school CSS hacks :D

I like it! Makes it a bit more clearer to the dev that this is very non-standard.

Pushed!

Does this also fix 🐛 navigation top bar edit button has strange active (?) colors Active ?

@berdir

yes. currently it is only one option that we have
Umami has global `a:hover` style.

What about MR I don't really like `hack` word.
`#extra-specificity-trick` probably will sounds better? :)

What about MR I don't really like `hack` word.
`#extra-specificity-trick` probably will sounds better? :)

Ya'll figure that out in Slack, and we can change the selector name at the end.

Does everything else look good?