indeterminate <input type=checkbox> definition confusing

[zcorpan]

https://html.spec.whatwg.org/multipage/input.html#checkbox-state-(type=checkbox)

The input element represents a two-state control that represents the element's checkedness state. If the element's checkedness state is true, the control represents a positive selection, and if it is false, a negative selection. If the element's indeterminate IDL attribute is set to true, then the control's selection should be obscured as if the control was in a third, indeterminate, state.

The control is never a true tri-state control, even if the element's indeterminate IDL attribute is set to true. The indeterminate IDL attribute only gives the appearance of a third state.

This text has been unchanged since its introduction in c1880df.

The indeterminate state is mapped to aria-checked="mixed" in html-aam, so it's not just about visual rendering.
https://w3c.github.io/html-aam/#el-input-checkbox

It also changes when the :indeterminate pseudo-class matches.

I get that the checked state is a boolean and that it is left as-is when indeterminate is set to true, but I still find the downplay of indeterminate confusing and I don't understand what it is trying to accomplish. If it means that it doesn't change what is submitted, then we should say so directly.

Can indeterminate be treated as a first-class concept?

[annevk]

In Firefox I observe four states with :checked and :indeterminate, which the specification supports, but Safari does not.

As for the text, I think obscuring the selection matches how it's exposed to ARIA. Doesn't seem to care only about visual appearance to me.

[zcorpan]

I guess you're right that it's not saying it's visual-only. I think it can be improved, though.

For context, I wanted to mention that HTML can represent an aria-checked="mixed" checkbox in aria-practices, but found it difficult to write something that was a correct statement from the above-quoted text.

I think to resolve this issue we could say that

• setting the indeterminate IDL attribute to true makes the checkbox "indeterminate" (exported dfn)
• indeterminate doesn't affect underlying checkedness, and does not affect form validation or form submission
• indeterminate affects how the control appears visually and through accessibility APIs, and affects the pseudo-class

That there is an interop difference between Firefox and Safari with the pseudo-classes is interesting. Do you have a demo?

[annevk]

<style>input + div { border:1em solid blue } input:checked + div { border-color:yellow }</style>
<input type=checkbox checked><div></div>
<input type=checkbox checked><div></div>
<script>document.querySelector("input").indeterminate = true</script>

[patrickhlauke]

not sure if this is the right thread to resurrect for this, but i'm wondering if there's any mileage in allowing indeterminate to be set using an actual attribute in HTML? i.e. being able to (statically) set an checkbox to be <input type="checkbox" indeterminate>, to match the same way this can be done but only for assistive technologies with <input type="checkbox" aria-checked="mixed">? again, it feels odd that it's possible to express this semantic concept in markup, but only for AT.

[annevk]

@patrickhlauke please file a new issue on that? I'd be supportive of adding that, but it might require some compatibility analysis. And maybe we can track someone down from the old Internet Explorer team who knows why it was done this way.