Repository navigation
Navigation block inherits parent border color when no text color is defined #79349
Description
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
- Create a theme without defining a Navigation text color in theme.json.
- Add a Group (or Stack) block.
- Insert a Navigation block inside it.
- Do not set any text color on the Navigation block.
- 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
-
Activate a block theme that does not define a Navigation text color in
theme.json. -
Create a new page or template in the Site Editor.
-
Add a Group (or Stack) block.
-
Insert a Navigation block inside the Group/Stack block.
-
Do not set any text color on the Navigation block.
-
Select the parent Group/Stack block.
-
Enable a border and set:
- Border Width: 1px
- Border Color: any visible color (for example, #E5E7EB)
-
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
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
himanshupathak95 commentedon Jun 26, 2026
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-colorclasses are inadvertently polluting the text color context in the editor/frontend. Modifying thecolor: inherit;rule directly might be tricky due to backwards compatibility with themes that rely on it.firdaus666 commentedon Jun 26, 2026
@himanshupathak95
I think the issue is actually related to the
borderslug. When a theme developer adds a color palette item with theborderslug, for example: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
borderslug intheme.jsonuntil this issue is fixed. This would likely reduce duplicate bug reports, since theborderslug currently appears to unintentionally affect the text color inside Group blocks.sanketio commentedon Sep 29, 2026
This looks like the same root cause as #70697. A palette slug of
bordergenerates the preset text rule.has-border-color { color: … !important }, andborder.jsx:336addshas-border-colorto any block that has a border colour, so the Group's text takes theborderpreset and the Navigation block inherits it throughcolor: 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.