fix: prevent CSS variable bleeding in nested tabs

[tahmidbintaslim]

Summary

Fixes #4200 - Nested tabs inherit styles from parent tabs

Problem

When nesting .tabs components inside each other, CSS custom properties like --tab-p and --tab-radius-min were inheriting from parent .tabs elements to nested .tabs elements. This caused style bleeding where nested tabs would incorrectly inherit sizing and styling from their parent tabs.

For example, if a parent tab was .tabs-lg, the nested tabs would also become large because they inherited the --tab-height value from the parent.

Solution

Reset all inheritable CSS variables in the base .tabs class so that each .tabs element starts with its own default values instead of potentially inheriting from a parent .tabs:

.tabs {
  @layer daisyui.l1.l2.l3 {
    @apply flex flex-wrap;
    /* Reset inheritable properties to prevent bleeding from parent .tabs */
    --tabs-height: auto;
    --tabs-direction: row;
    --tab-height: calc(var(--size-field, 0.25rem) * 10);
    --tab-p: 0.75rem;
    --tab-radius-min: calc(0.75rem - var(--border));
    height: var(--tabs-height);
    flex-direction: var(--tabs-direction);
  }
}

Testing

• All existing tests pass
• Added specific tests for the nested tabs fix that verify CSS variable resets exist
• Build succeeds without any errors

Related

• Discussion: Nested tabs style override #4200
• Related PR: feat: refactor tab component #4213 (draft by @pdanpdan with different approach)

[Copilot]

Pull request overview

This PR fixes issue #4200 where nested .tabs components inherit CSS custom properties from their parent tabs, causing style bleeding. The solution adds CSS variable resets in the base .tabs class to ensure each tabs component starts with default values rather than inheriting from parent elements.

Key changes:

• Reset inheritable CSS variables (--tabs-height, --tabs-direction, --tab-height, --tab-p, --tab-radius-min) in the .tabs class
• Include incidental formatting changes to gradient and border-radius declarations

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

These CSS variable declarations duplicate the same values already defined in the .tab class (lines 18 and 26). While resetting these variables in .tabs is necessary to prevent inheritance from parent .tabs elements, consider whether these specific variables need to be reset here given that:

1. The size modifiers (.tabs-xs, .tabs-lg, etc.) set --tab-p and --tab-radius-min on the .tab element using the child selector & > .tab, not on .tabs itself
2. Only --tab-height is actually set directly on .tabs by the size modifiers

If the goal is to prevent nested .tab elements from inheriting from parent .tab elements, these resets in .tabs may not achieve that since CSS variables inherit through the DOM tree regardless of selector specificity. The .tab class already defines these variables, so nested .tab elements would use those values, not values from a parent .tabs.

Suggested change

	--tab-p: 0.75rem;
	--tab-radius-min: calc(0.75rem - var(--border));

[Copilot]

This formatting change appears to be unrelated to the nested tabs fix. The multi-line gradient definition has been reformatted to use fewer lines. While this doesn't break functionality, it's generally better to keep formatting changes separate from bug fixes in different commits or PRs for easier code review and git history tracking.

Suggested change

	#0000 calc(69% - var(--border)), var(--tab-border-color) calc(69% - var(--border) + 0.25px),
	var(--tab-border-color) 69%, var(--tab-bg) calc(69% + 0.25px);
	#0000 calc(69% - var(--border)),
	var(--tab-border-color) calc(69% - var(--border) + 0.25px),
	var(--tab-border-color) 69%,
	var(--tab-bg) calc(69% + 0.25px);

[Copilot]

Similar to lines 29-30, this formatting change appears to be unrelated to the nested tabs fix. Consider keeping formatting changes separate from bug fixes for better code review and git history tracking.

[pdanpdan]

So mainly Copilot changes something and then comments that the change should not be applied because it does nothing? :)

The original problem was already fixed - the draft PR is kept open because it has some interesting further development ideas, but I have no bandwidth for the moment to implement them.

[tahmidbintaslim]

@pdanpdan The copilot was actually doing review. But You're absolutely right, and I apologize for the confusion!

After reviewing the git history, I can see that commit 15044b2f77e by @pdanpdan already properly fixed the nested tabs style bleeding issue back on Nov 1, 2025. The fix used direct child selectors (> .tab) which is the correct approach.

My changes added --tab-p and --tab-radius-min resets to the .tabs base class, but looking more carefully at the current code, these variables are already properly scoped in the .tab class definition itself, so they don't inherit from parent .tabs elements.

Closing this PR as the original issue was already resolved. Thanks for pointing this out!

Regarding the "interesting further development ideas" mentioned in PR #4213:

• Try to reduce the component size
• Implement .tabs-start and .tabs-end for vertical tab layouts
• Keep the existing interface unchanged

These are more ambitious refactoring goals that go beyond just fixing the style bleeding issue.