feat: add defaultindeterminate attribute to checkbox for setting indeterminate declaratively

[Chris Holt (chrisdholt)]

Previous Behavior

On the HTML Platform there is currently no way to have indeterminate exist at runtime without hydration, this issue also exists with the current Fluent checkbox.

New Behavior

This PR proposes a new defaultindeterminate attribute to support setting indeterminate declaratively. The proposed approach follows the discussion and direction provided in whatwg.

[github-actions]

📊 Bundle size report

✅ No changes found

[github-actions]

Pull request demo site: URL

[github-actions]

🕵🏾‍♀️ visual changes to review in the Visual Change Report

vr-tests-web-components/Badge 1 screenshots

Image Name	Diff(in Pixels)	Image Type
vr-tests-web-components/Badge. - Dark Mode.normal.chromium.png	443	Changed

[John Kreitlow (radium-v)]

Is there a true need for a dirty-indeterminate state? We don't have a separate state for dirty-checked.

[Chris Holt (chrisdholt)]

There is a reason for this, and I think it's one-of-a-kind situation (maybe I missed something simpler). Consider the lifecycle of defaultindeterminate.

1. A server-rendered indeterminate means we hook off the attribute for initial visual styling (avoid using states which should be client-side only). The checkbox appears as indeterminate.
2. Click the checkbox => checkbox shows checked and no longer indeterminate, attribute styling is preserved for defaultindeterminate
3. Click the checkbox again => checkbox is unchecked, attribute styling is preserved for defaultindeterminate

We need to preserve the attribute that's passed from the client (we should not remove this or toggle upon user interaction). We need a way to essentially say, "This is no longer indeterminate" while preserving the attribute from user-land. I chose a state here because it explicitly applies client-side.

[Chris Holt (chrisdholt)]

I'm open to naming on the state, but absent another solution it seems the most elegant to address what is purely a styling problem post-user-interaction.

[Chris Holt (chrisdholt)]

I think this still needs to exist...or I'm being dense.

:host([defaultindeterminate]):not(:state(${indeterminateState})) {}

In a scenario where we render DSD, defaultchecked manages the initial visual presentation. On user interaction, CSS state would no longer be indeterminate (as above)...but the host styling would still apply, because the attribute still exists.