radix-ui / themes

Radix Themes is an open-source component library optimized for fast development, easy maintenance, and accessibility. Maintained by @workos.

Home Page:https://radix-ui.com/themes

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Switch inside of a Tooltip is not rendered correctly

janmonschke opened this issue · comments

Description

When a Switch is rendered inside a Tooltip, the Switch's background color is not correct when it's unchecked.

Actual behaviour

Screenshot 2024-04-05 at 20 54 00 Screenshot 2024-04-05 at 20 54 10

Example code:

<Heading mb="2">Switch with a tooltip</Heading>
<Tooltip content="test tooltip content">
  <Switch defaultChecked={false} />
</Tooltip>
<Heading my="2">Switch without a tooltip</Heading>
<Switch defaultChecked={false} />

Codesandbox: https://codesandbox.io/p/sandbox/radix-themes-tooltip-switch-g7jgg5

Expected behaviour

The background color of the Switch inside the Tooltip matches the unchecked color of the standalone Switch.

Meta

  • Reproduced in latest Firefox and Chrome
  • Using @radix-ui/themes version 3.0.2 but was broken in 3.0.0 as well.

Hey,

Observing the inspector looks like it occurs because the CSS of the switch uses the data-state (checked | unchecked) attr as a selector, but, the Tooltip component replaces the data-state also (closed | delayed-open | instant-open).

Every time that you set a tooltip your first child will receive this attr (data-state), and in this case, this causes a conflict of styles.

I don't know if it's possible to replace this class selector to not watch the data-state attribute, and if this change, can hurt the accessibility principles of radix.

But you can quickly fix this using an ancestor in the switch component like a span element. Using this way, the data-state of the tooltip will change states on the ancestor element (span), and not will interfere with the data-state of the switch.

Codesandbox: https://codesandbox.io/p/sandbox/radix-themes-tooltip-switch-forked-qmlwq7

Gotcha, the <span /> workaround is good enough for me at the moment. This should probably be mentioned in the docs though, wdyt?

@benoitgrelard do you know of a way around this issue?