paper-checkbox should have an indeterminate state

[KyLeggiero]

For lists with a "Select All" checkbox, or for displays like this compatibility matrix, an in-between (commonly called indeterminate) state is necessary. Here are some examples:

I propose the following addition:

<paper-checkbox indeterminate> label</paper-checkbox>

Where this will always give the checkbox an indeterminate state. This might override the checked state, so the following:

<paper-checkbox indeterminate> label</paper-checkbox>
<paper-checkbox checked indeterminate> label</paper-checkbox>
<paper-checkbox indeterminate checked> label</paper-checkbox>

would all render exactly the same way.

[KyLeggiero]

Moved from general Polymer issue 1749

[adalinesimonian]

This is just my two cents, and one not necessarily representative of the Polymer team's.

The paper- elements, as I understand it, are designed to implement the Material Design specification. However, the Material Design specification does not provide any model for tri-state checkboxes. Hence, a question of whether or not paper-checkbox should/shouldn't have an indeterminate state really would be a question of why Material Design should/shouldn't allow for indeterminate checkboxes.

An indeterminate checkbox which allows the user to select between all three states would be downright confusing, but I think we can all agree on that. Instead, as the example you referred to demonstrates, tri-state checkboxes seem to have uses that greatly depend on context.

For a compatibility chart, I would argue that checkboxes, an input element, wouldn't be the best choice. Instead, an icon or image of some sort would be better suited for the situation and would do no less of a fine job at it.

Now, for hierarchical lists, or trees, such as those common in the advanced options provided in installers, indeterminate checkboxes prove useful for indicating whether or not items down in the hierarchy are selected in full, not at all, or partially, and users are most familiar with their use in such a fashion [citation needed]. However, these controls aren't something to expect in the vast majority of web applications geared at the common end-user, at whom the iron and paper elements are targeted (to my knowledge), and instead are found in more advanced/technical scenarios [citation needed].

However, therein is my concern: if, in UX design, these checkboxes prove themselves to have such narrow applicability, would it be the right step to take to then add support for such a relatively uncommon use-case to an element which is meant for widespread general use?

Instead, I think it would be a better to implement a selectable tree element outside of the scope of the paper- repositories, and have it use its own implementation of a checkbox. Then, not only is there an element which will prove itself much more useful and functional than a tri-state checkbox on its own, but the quandary of adding edge-case functionality to a general-purpose element is avoided entirely.

[notwaldorf]

Yeah, unfortunately I think I'll have to agree with @vsimonian. paper-checkbox is the implementation of the Material Design checkbox, which is an on-off checkbox, and I do not think outside of the tree example, a tri-state checkbox makes sense. The most common use of checkboxes is something like:

Foods I like (check all that apply):
<paper-checkbox>Pizza</paper-checkbox>
<paper-checkbox>Donuts</paper-checkbox>
<paper-checkbox>Nothing else I am on a pizza-donuts diet</paper-checkbox>

A tri-state in this case makes no sense: I "kind of" like pizza? I think what you're actually looking for is some sort of "clickable tree node", which we don't have at the moment :(

[notwaldorf]

I've created PolymerElements/paper-elements#24 as a feature request, but it hasn't been prioritized or discussed, so this is not a promise we'll implement it immediately :)

[grokys]

There are places outside of a treeview where indeterminate states in checkboxes are useful, in particular when editing an aggregate of multiple records where the indeterminate state indicates that there are a mixture of trues and falses in the records being edited.

http://ux.stackexchange.com/questions/76744/denoting-multiple-values-for-the-same-checkbox-or-radiobutton/76781

I do agree that the applicability is probably rather narrow, but the lack of an indeterminate state in the material design specification IMO shouldn't be the reason not to include this in Polymer - polymer is likely to be used for applications that wouldn't be a traditional phone UI.

[KyLeggiero]

@grokys and his linked UX.SE question brings up interesting scenarios I hadn't thought of. Editing multiple items (values in a table, characters in rich text, files in a directory, etc.) would also cause an indeterminate/intermediate state to an otherwise binary element if some have the property and some don't.
For instance, if you select 100 files and one is read-only, would you have the "Read-only" checkbox in their properties say that they are all read-only, or that none are?

[KyLeggiero]

@notwaldorf if we are to close this because Material Design does not provide an indeterminate state, then may I ask if there is anywhere I can provide feedback or feature requests on Material Design?

[userquin]

According to WCAG 2.0, checkbox must allow mixed value:

https://www.w3.org/TR/wai-aria/roles#checkbox

https://www.w3.org/TR/wai-aria/#checkbox

This is not an enhacement for the element, it is a11y issue and must be marked as a bug.

[notwaldorf]

Ah, got, it, thanks for the explanation. I'll re-open #124 and re-triage. Thanks! (this issue was about the UI, which is different) 🎈

[MMJM]

+1 for a tri-state checkbox. In our case of legal questions there must be a specific indication of yes or no so there is a case for an unanswered state.

[KyLeggiero]

@MMJM I might be hurting my own argument here, but at least as a workaround for now, you probably should use a dropdown with options like "Answer Required" (default, disabled), "Yes", and "No".