remove the indeterminate class from Checkbox

[nicholasrice]

This issues tracks a follow-up to #4078.

Checkbox adds the indeterminate class to the custom element host when the control is in an indeterminate state. #4076 defines the intent of components to style themselves without hoisting classes to the element host.

This is problematic for the Checkbox because the Checkbox does not expose a indeterminate content attribute, only the indeterminate IDL attribute. The reason for this is parity with the <input type="checkbox" />.

There are a few options I can think of to address this:

1. Add an indeterminate content attribute (are there any known downsides to this? Why didn't the platform do this?)
2. Expose a IDL property that is a CSSStyleSheet that can be added / removed from the shadow root based on indeterminate state. This feels pretty un-ergonomic but it's an option
3. Wait for the platform to add custom state to custom elements that can be selected for by CSS (Custom pseudo-classes for host elements via shadow roots (:state) WICG/webcomponents#738)
4. Others?

[EisenbergEffect]

@chrisdholt I wanted to draw your attention to this. This came up during our sync today with the Blazor folks. It would be nice to have this as an HTML attribute so that it can be set from HTML by Blazor. If it's only a property, Blazor can't set it and their customers would be forced to a JS interop layer for any checkbox they need to use this on, which isn't ideal.

[chrisdholt]

@chrisdholt I wanted to draw your attention to this. This came up during our sync today with the Blazor folks. It would be nice to have this as an HTML attribute so that it can be set from HTML by Blazor. If it's only a property, Blazor can't set it and their customers would be forced to a JS interop layer for any checkbox they need to use this on, which isn't ideal.

Thanks @EisenbergEffect - curious if this is the case w/ standard inputs as well where this is still only an IDL attribute?

[EisenbergEffect]

I think it's a property but not an attribute on built-ins. Per Nick's comment...this actually seems like an odd thing for the platform. We should probably bring it up with the HTML folks as something to address. In Blazor's case specifically, they can technically only call the setAttribute() API. So, if it's not an attribute, their customers can't set it without custom JS interop.

[chrisdholt]

I think it's a property but not an attribute on built-ins. Per Nick's comment...this actually seems like an odd thing for the platform. We should probably bring it up with the HTML folks as something to address. In Blazor's case specifically, they can technically only call the setAttribute() API. So, if it's not an attribute, their customers can't set it without custom JS interop.

I'm good making this change, I think I'll also bring up an issue in Open-UI to elevate it there. Let's definitely track this as a larger HTML Platform improvement that's needed. Alternatively, they may push back and if so this seems like it would be an issue for Blazor all up. I'm good with making this change. We'll get it slotted.

[EisenbergEffect]

There might be a similar type of issue with the listbox value or selectedindex as well. @nicholasrice is going to be working on the Blazor wrapper stuff and will be able to provide more details as he proceeds. All-in-all we think that working with Blazor is going to help us find little things like this that we can do to improve the components. Many of these fixes should also make things better for React developers as well.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[janechu]

Unfortunately @microsoft/fast-components has been deprecated for some time.