Front-end theme styles can bleed into Navigation

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.

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 (example CodePen), 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 selector 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

@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 #3501662: navigation top bar edit button has strange active (?) colors?

@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?

Sorry to be that guy but MR needs manual rebase.

No worries.

Before I do a rebase, can I get a review on the methodology, etc, from the maintainers/committers (See #26)?

This will touch so many files, I'll be rebasing forever as it just sits here (it's already been waiting forever).

First thought, instead of calling it a hack, can we call it override?

Got hit by this on a client project. Seems only outstanding issue is the name extra-specificity-hack, do like the idea of override. So after that change just needs a rebase and believe its good to go?

Maybe a CR if anyone has written their own components?

• Wrapping styles in the extra specificity selector to force the style to be applied: OK
• extra-specificity-hack/extra-specificity-trick: extra-specificity-hack. We have a long history of CSS using "hack" to find workaround for browser support

Sounds good. I'll likely be able to work on it this weekend. Thanks :)

Current MR is all FUBAR. Going to create a new one.

On Slack, @catch pointed out that this could be a blocker for #3557578: Mark Navigation as a stable module. I personally think it's fine for us to mark the module stable and commit this whenever it's ready. That said, this is a pretty nasty DX bug so it would be good to get this fixed sooner rather than later.

This is ready for review! I did extensive testing, and it should be good to go!

Lets get this reviewed, and committed asap. It touches every single CSS, so it's easy to get out of date (and I've already re-done it 3x now!)

Tested this out following the steps from the summary

Added

button:hover,
input[type="submit"]:hover {
  background-color: red;
}

To a file in umami and am seeing the red hover on the button.

Applying the MR the CSS no longer applies.

Tested this on a random side project I work on where links were changing size and it was fixed there too.

LGTM

Yay! Lets get this in before it gets stale!

Committed and pushed ae8ac5ed60c to 11.x and 82a36af1315 to 11.3.x. Thanks!

I noticed this is breaking the Gin Top bar in Gin 5.x when in the admin theme. Should gin then go extra-extra-specificity to override this? Or would this be a follow-up in Core?

Yeah, Gin will need to add specificity. I wonder if we should have a CR

Okay thanks, I created this issue in Gin: #3560487: Gin Top Bar styling is fully gone in 11.3.x

Yes I suppose it could affect other themes or modules, so perhaps a general announcement about it could be helpful

Instead of #extra-specificity-hack in core we should just introduce a real ID.

I said basically the same thing in 36, but it was never addressed

See you in #3569668: Broken styles for contextual links for blocks when editing navigation layout 🤓