Skip to content

Navigation block inherits parent border color when no text color is defined #79349

Open

Description

@firdaus666

Description

I'm currently developing a Full Site Editing (FSE) theme and noticed a behavior that may be worth discussing.

The Navigation block does not appear to have a default text color when neither the theme nor the user explicitly defines one.

For example:

  • No text color is defined in theme.json
  • No text color is selected by the user
  • A Navigation block is placed inside a Group/Stack block
  • The parent Group/Stack block receives a border color

Because Navigation items use:

.wp-block-navigation .wp-block-navigation-item__content.wp-block-navigation-item__content { color: inherit; }

the navigation links inherit the color from their parent context.

As a result, changing the border color of the parent block can indirectly affect the visible color of navigation links, even though no text color was intentionally configured.

Steps to Reproduce

  1. Create a theme without defining a Navigation text color in theme.json.
  2. Add a Group (or Stack) block.
  3. Insert a Navigation block inside it.
  4. Do not set any text color on the Navigation block.
  5. Set a border color on the parent Group/Stack block.

Expected Behavior

Navigation links should retain a predictable default text color unless a text color is explicitly configured by the theme or user.

Actual Behavior

Navigation links may inherit colors from the parent context, causing the menu color to change unexpectedly when unrelated styling (such as border color) is modified.

Additional Context

Adding an explicit Navigation text color in theme.json resolves the issue:

{ "styles": { "blocks": { "core/navigation": { "color": { "text": "var(--wp--preset--color--contrast)" } } } } }

Because of that, I'm not sure whether this should be considered a bug or expected behavior. However, from a theme developer perspective, the lack of a default/fallback text color can lead to unexpected results when Navigation relies entirely on inherited colors.

Question

Is it intentional that Navigation relies entirely on inherited colors when neither the theme nor the user defines a text color?

From a theme developer perspective, this can produce unexpected menu color changes when parent blocks introduce styling that affects inherited colors.

Step-by-step reproduction instructions

  1. Activate a block theme that does not define a Navigation text color in theme.json.

  2. Create a new page or template in the Site Editor.

  3. Add a Group (or Stack) block.

  4. Insert a Navigation block inside the Group/Stack block.

  5. Do not set any text color on the Navigation block.

  6. Select the parent Group/Stack block.

  7. Enable a border and set:

    • Border Width: 1px
    • Border Color: any visible color (for example, #E5E7EB)
  8. Observe the Navigation links.

Expected behavior

Changing the border color of the parent block should only affect the border.

Actual behavior

The Navigation links inherit the parent color and their text color changes, even though no Navigation text color was explicitly configured by the theme or user.

Screenshots, screen recording, code snippet

Image Image Image

Environment info

  • WordPress Version 7.0 , Gutenberg Version 23.4.0, Theme - Custom Theme
  • Google Chrome
  • Windows 10

Please confirm that you have searched existing issues in the repo.

  • Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

  • Yes

Please confirm which theme type you used for testing.

  • Block
  • Classic
  • Hybrid (e.g. classic with theme.json)
  • Not sure

Activity

  1. added
    [Type] BugAn existing feature does not function as intended
    on Jun 19, 2026
  2. himanshupathak95 commented on Jun 26, 2026

    @himanshupathak95
    Contributor

    Thanks for reporting this and providing detailed reproduction steps!

    To answer your question: yes, the use of color: inherit; on the Navigation block is likely an intentional design choice. It allows the navigation links to naturally adapt to the text color of their parent container (simplest use case I can think of is - automatically matching a dark-mode header group without needing to manually recolor the links), and can see the discussion and intentional implementation of this in PR #44578: Navigation: Try fixing link color in some TT2 contexts.

    However, it somewhat makes sense that applying an unrelated border color to the parent shouldn't inadvertently change the text color of the inherited links. This seems to be a side effect for me.

    The simplest way to avoid this side-effect is to define a fallback text color

    {
      "styles": {
        "blocks": {
          "core/navigation": {
            "color": {
              "text": "var(--wp--preset--color--contrast)"
            }
          }
        }
      }
    }

    Worth considering if we should look into whether the block supports or has-[color]-border-color classes are inadvertently polluting the text color context in the editor/frontend. Modifying the color: inherit; rule directly might be tricky due to backwards compatibility with themes that rely on it.

  3. firdaus666 commented on Jun 26, 2026

    @firdaus666
    Author

    @himanshupathak95

    I think the issue is actually related to the border slug. When a theme developer adds a color palette item with the border slug, for example:

    {
      "slug": "border",
      "name": "Light Steel Gray",
      "color": "hsl(210 5% 70% / 1)"
    }
    

    and then uses that color as the Group block border color, the text color inside the Group block also changes to the border color.

    In my opinion, the border color should only be applied to the border and should not affect the text color.

    It looks like the border color slug is also being treated as a text color somewhere, causing the Group block text to inherit the border color unexpectedly.

    Alternatively, it might be be worth adding a note to the documentation recommending that theme developers avoid using the border slug in theme.json until this issue is fixed. This would likely reduce duplicate bug reports, since the border slug currently appears to unintentionally affect the text color inside Group blocks.

  4. sanketio commented on Sep 29, 2026

    @sanketio
    Contributor

    This looks like the same root cause as #70697. A palette slug of border generates the preset text rule .has-border-color { color: … !important }, and border.jsx:336 adds has-border-color to any block that has a border colour, so the Group's text takes the border preset and the Navigation block inherits it through color: inherit.

    Measured on trunk, the effect does not depend on which border colour is chosen — a Group with an unrelated border colour recolours identically. Mechanism and a backward-compatibility check of the candidate fixes are on #70697.

    Use of AI Tools

    Authored with Claude Code under direction and review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    [Block] NavigationAffects the Navigation Block[Type] BugAn existing feature does not function as intended

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions