feat: Allow More Flexibility in DBTabs Children

[timgrohmann]

Proposed changes

Change the CSS that controls visibility of tab content in DBTabs to be more flexible without breaking current behaviour. See #4893

Types of changes

• Bugfix (non-breaking change that fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (improvements to existing components or architectural decisions)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0b0520b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[nmerget]

@timgrohmann thank you for your PR.

Right now, there is one issue with this implementation. You aren't able to have DBTabs inside another DBTabs.
The :has selector uses the index of the tab which will be 0 for the first tab and also for the first "inner"-tab. The content would be shown all the time. You see this behavior in the react showcase where we have nested DBTabs.

Why so you want to change the selector in the first place?

P.S.: Sadly, we need to refactor the DBTabs anyways. Right now we use input type=radio which is pretty smart because it handles the state and the keyboard navigation by the browser, but tools like axe-core aren't allowing the tab role on inputs see this for more information. Therefore, we need to refactor the DBTabs - probably we'll use ´´ or <a> as a default with a internal state so the pure CSS solution will be obsolte in the future.

[timgrohmann]

@nmerget Ah yes, I didn't consider nesting the DBTabs. We want to remove the direct sibling constraint to have a more flexible structure for the tabs – we are currently facing a design requirement that is difficult/ugly to implement with the sibling constraint. Maybe I'm just too stupid to write good CSS, who know's :D

When are you planning the refactoring you mentioned?

[nmerget]

There are some issues with the "tabs' label. All of them should be resolved with the refactoring. And it would be great if the developers could choose between a button and an a as Tab-Item.
@LSchroff are the Tabs on the roadmap in the near future?