[checkbox] Does the checkbox need an implementation?

[colbywhite]

Does the checkbox need an implementation?

I took a stab at implementing an oui-checkbox component based on the Checkbox proposal. During the process however, I ended up with some questions about this specific proposal.

I began with a standard web component that used the following shadow DOM.

<!--shadow DOM-->
<label part="label">
  <input part="indicator" type="checkbox" />
  <slot></slot>
</label>

<!--usage-->
<oui-checkbox>Label</oui-checkbox>

There's probably other ways to structure that shadow DOM, but pretty quickly I hit two different issues:

• I was breaking native form handling
• I was just forwarding most of the attributes from <oui-checkbox> to <input> and by using a shadow DOM

<input
  part="indicator"
  type="checkbox"
  ?checked="${this.checked}"
  ?disabled="${this.disabled}"
  ?autofocus="${this.autofocus}"
  .value="${ifDefined(this.value)}"
  .name="${ifDefined(this.name)}"
/>

In beginning to figure out ways to make forwarding attribute simpler and not break <form>, I realized that I could just extend the built-in HTMLInputElement directly. Once I quickly prototyped that, I ended up with a very thin component.

export class OuiCheckboxBuiltIn extends HTMLInputElement {
  connectedCallback() {
    this.type = "checkbox";
  }
}

window.customElements.define("oui-checkbox-built-in", OuiCheckboxBuiltIn, {
  extends: "input",
});

Everything that's proposed in the current proposal is already accomplished via <input type="checkbox">. With such a thin component, I then began to ask myself what's the real purpose of this component. Looking back through the proposal, there is very little difference between an <oui-checkbox> and an <input type="checkbox">.

So I bring that question back to the group: What should be the goal of checkbox? I very well may be ignorant to a key piece of info. But at bare minimum there doesn't seem to be a need for a web component here. It would be helpful from a simplicity standpoint if browsers had a <checkbox> component built in as opposed to the current <input type="checkbox">, but the former would probably be implemented as an alias of some sort to the latter under the covers. (Just a guess.) So an intermediate component doesn't seem all that useful if the goal of this proposal is to suggest that browsers (or maybe HTML itself) simplify the current <input type> mechanics and/or syntax.

I could also see a <checkbox> component that is smart enough to know when to flip to a toggle style UI, but that doesn't seem to be the goal of the proposal.

But I may be missing something.

What's the group's thought on checkbox? Is this too simple of a component to warrant an intermediate web component? Or perhaps there's a different goal for this, maybe something that combines some different form of <input>?

[gregwhitworth]

Thanks @colbywhite, great questions

So I bring that question back to the group: What should be the goal of checkbox?

The goal of Open UI in general is to allow styleable and extensible controls/components that ship with the browser and ensuring accessibility by default. Currently the native checkbox you can get quite far relative to other solutions especially with the new accent-color. But if you want to replace the glyph you don't actually have this option so you'll need to replace what's there. I'll also note that I don't agree with the current proposal from an anatomy perspective. I would expect something like this (off the top of my head):

<oui-checkbox>
    <slot name="label-container">
        <label part="label">
            <slot></slot>
        </label>
    </slot>
    <slot name="indicator-container">
        <div part="indicator">
            <slot name="indicator"></slot>
        </div>
    </slot>
</oui-checkbox>

This aligns more with the paradigm we're following for iterative or complete replacement of the various parts. Also, the oui-checkbox will have form involvement, the checked value will reside on oui-checkbox. So a KEY difference here is that it comes with a label and will have interoperable eventing applied to the parts. Given its relative simplicity it's easy to dismiss but there are NUMEROUS top sites that have inaccessible.

So an author would only have to do the following now, akin to what they do when building native applications:

<oui-checkbox name="testing" checked>Testing Checkbox</oui-checkbox>

And this would result in label + checkbox toggling, a label added by default (enabling improved linting/tooling if it's not included, etc).

And then of course, you can make REALLY complex ones that have SVG within them and text. This is actually why I abandoned the Psuedo element for these toggle type components. There is a great collection of simple to complex variants here.

I'll note that I'm not saying that one couldn't accomplish some of the above via complex CSS background gradients but that's also way more complictated than it needs to be.

And finally, I'd really like <input> to be legacy tech a decade or so from now that only us old web folks know about and you reach for the specific component you're wanting to work with and all of them follow the exact same model (this is not true of the input variants nor other controls).

Hope this helps. I'd love to see someone tackle the spec and continue to iterate on your component.

[andrico1234]

I ran into similar issues when trying to prototype an oui-checkbox component, including the same confusion around anatomy.

I'm in agreement with Greg that having a dedicated component that offers full UI customization and is accessible by default is ultimately a positive, even if the implementation is a thin layer on top of an existing HTML element. I also found that enabling correct focus, disabled, and form behaviours caused the complexity of my own oui-checkbox implementation to grow.

I would have loved references to the related GitHub issues from within the proposal docs. Even if for just posterity as I found myself digging through old GitHub issues looking for explanations.

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.