primitives icon indicating copy to clipboard operation
primitives copied to clipboard

[Label] hover effect should match label element

Open penx opened this issue 3 years ago • 6 comments

Bug report

Current Behavior

If you hover over a <label /> associated with a Radix Checkbox (or <input />), the checkbox's hover state is triggered.

If you hover over a <LabelPrimitive.Root /> associated with a checkbox (or <input />), the checkbox's hover state is not triggered.

Expected behavior

The behaviour of <LabelPrimitive.Root /> should match <label /> .

If you follow the documentation for Checkbox:

https://www.radix-ui.com/docs/primitives/components/checkbox

It shows usage with a standard label element, including a hover effect. If you then switch to using Radix' label component, you lose the hover effect.

Reproducible example

Hover over the labels in this example:

https://codesandbox.io/s/ecstatic-rosalind-eky4tl

Your environment

Software Name(s) Version
Radix Package(s) react-checkbox, react-label 0.1.5
React 17.0.2
Browser Chromium 98.0.4758.109
Operating System macOS 11.6

penx avatar Mar 08 '22 12:03 penx

Hi @penx,

Thanks for raising this.

Whilst I agree it would be nice to match that, I don't think it is possible to force a CSS state. The only way I think we could get "close" would be to introduce our own data-hover state on controls which users would have to style on top of :hover. Something like that.

:hover, [data-hover] { … }

Which is not ideal and not really obvious for users.

The easiest thing to do if you have control might be to nest the control inside the Label and style the hover this way:

.label:hover .control, .control:hover { … }

Can you think of other ideas?

✌️

benoitgrelard avatar Mar 30 '22 13:03 benoitgrelard

Can you think of other ideas?

Use a label element? 😁

I'd be keen to know why this isn't a label element already, I'm sure there's good reason but I wasn't able to figure it out from the past PRs I looked at.

penx avatar Mar 30 '22 13:03 penx

Another thought is that browser vendors should match the label hover effect when role="label" is used, so unless this has already been decided against by vendors (or is part of a spec) perhaps it's worth raising issues against webkit, chromium and firefox.

I don't see any relevant open or closed issues in any of these trackers when searching for "role label hover"

penx avatar Mar 30 '22 13:03 penx

historically, it needed to be role="label" because the native one wouldn't work with the custom button controls, but those controls have since been rejigged (checkbox etc.) to work better with native label so isn't likely necessary for those anymore.

there have been a few separate occasions i've mentioned it can probably switch to label but team would need to look into it to make sure.

the only case it might be needed is custom select so that clicking label focuses custom select but could add a focus listener to the native one perhaps and redirect it.

jjenzz avatar Mar 30 '22 14:03 jjenzz

Ok cool, we'll do another pass to see if we can improve things here.

benoitgrelard avatar Apr 04 '22 12:04 benoitgrelard

Happy to see there's an open discussion around this topic! I really appreciate it. I was a bit surprised of seeing span as label and the mouse pointer behaviour.

Let not forget the first rule of ARIA: https://www.a11y-collective.com/the-first-rule-for-using-aria/

keul avatar Sep 21 '22 08:09 keul