Add RichCheckbox component

[acelaya]

Add a component that looks visually like the existing Radio from RadioGroup, but displays a checkbox icon and works on its own.

Note

This component does not follow a common pattern where you have a focusable/actionable individual checkbox input with a label, and optionally a helper text underneath. Instead, this component is focusable/actionable entirely, and has some opinionated styles which try to make it visually consistent with the radio group radios.

This has the side effect that it cannot contain other actionable elements, like links. If we ever need that kind of pattern, it would need to be implemented separately, probably by composing the existing Checkbox component with some extra capabilities.

rich-checkbox-2025-04-28_11.23.21.mp4

Note

There's some functionality we may need in future, but I decided to not implement it yet, and wait for an actual use case to appear.

• Allow a name to be provided, so that a hidden input with that name is rendered, allowing this component to be used with "traditional" forms.
• Support disabling the component, as we do with RadioGroup radios.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (ea06dec) to head (7fac37b).

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #1962   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           70        71    +1     
  Lines         1314      1325   +11     
  Branches       484       489    +5     
=========================================
+ Hits          1314      1325   +11     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[acelaya]

I choose RichCheckbox as opposed to Checkbox, but I'm open to suggestions on a better name.

[acelaya]

The text colors are consistent with the ones set in #1955

[robertknight]

On macOS (Safari and Chrome) the title text and checkbox are slightly misaligned in RichCheckbox, compared to Checkbox.

Checkbox:

RichCheckbox:

[acelaya]

On macOS (Safari and Chrome) the title text and checkbox are slightly misaligned in RichCheckbox, compared to Checkbox.

Hmm, interesting. It might also be the case in other OSes, but I just didn't notice it.

I reckon I took the same styles we used for the RadioGroup's radios, but it could be that there's some slight difference in the icon and this needs adjustments. I'll take a more careful look.

[acelaya]

On macOS (Safari and Chrome) the title text and checkbox are slightly misaligned in RichCheckbox, compared to Checkbox.

Ok, this was a general issue. The alignment was a bit brittle, manually set via vertical margins, just closely depend on the size of the icon.

I have refactored the whole component to use a grid layout with 2 columns, where each row is vertically align.

[robertknight]

It feels unfortunate to me to have two separate checkbox components. Any new developer using the library has to try and figure out which they should use in a particular context. Also we may get unintended divergence where an improvement is implemented in one but not the other.

We definitely have some use cases where we need a subtitle and some without, but do we have a clear reason to have two different hover styles? It seems there is a design decision here. If we need to do an incremental rollout of a change then we could have different variants.

[acelaya]

As per my comment in slack https://hypothes-is.slack.com/archives/C4K6M7P5E/p1746005737334339, I'm closing this for now, as it is opening a whole new discussion that is blocking other tasks.

We can come back to this topic later, and decide how to better address it.