[Bug 13508] Fully support tri-state and indeterminate controls

https://www.w3.org/Bugs/Public/show_bug.cgi?id=13508

Travis Leithead [MSFT] <travil@microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |travil@microsoft.com
           Assignee|dave.null@w3.org            |travil@microsoft.com

--- Comment #4 from Travis Leithead [MSFT] <travil@microsoft.com> ---
(In reply to comment #0)
> HTML5 should provide true support for tri-state checkboxes and menu items
> (those with states of checked, unchecked, and
> indeterminate/mixed/undefined), as well as other controls with
> indeterminate/mixed/undefined state. This will let user agents provide
> standardized user interface for such controls, and let assistive technology
> provide alternative input and output for them. Not providing this would mean
> authors and developers would still have to implement custom controls and
> behaviors for an extremely common feature, and these would not be compatible
> with assistive technology. 

The major problem here seems to be that assistive technology isn't [yet]
equipped to deal with HTML5's indeterminate checkbox behavior. The reason why
this is likely hard to do, is because an AT can't know just based on the
markup, whether the behavior of the indeterminate checkbox should be truly
tri-state (e.g., unset -> indeterminate -> set (repeat)) or simple pseudo
tri-state (e.g., indeterminate -> set -> unset -> set -> unset (etc.)). The web
developer can model either behavior with JavaScript with the current HTML5
control.

> We recognize that for checkbox controls there are backward compatibility
> issues with the Boolean checked attribute; this could be addressed by any of
> a number of means, such as providing a new attribute to indicate a
> indeterminate/mixed/undefined state or changing the semantics and behaviors
> of the existing indeterminate attribute so that it was no longer defined as
> being purely cosmetic.

The current pseudo-tri-state checkbox is itself a very useful concept, not one
that we'd like to change. Having said that, the true tri-state control is also
very useful--though I disagree with the use cases cited in this bug (the
behavior for setting the checkbox back to indeterminate to mean "undo" is
probably not right).

As noted, a true-tri-state control could be added in several ways: 1) a new
element (e.g., <threebox></threebox>), 2) extending the <input> types (e.g.,
<input type="tristatebox">), or 3) signaling the tri-state behavior to existing
checkboxes (e.g., <input type="checkbox" tristate>).

I don't really like the first option because it introduces a new element that
is very, very similar to the input type=checkbox in so many respects. It also
has to define a content model (which would probably be similar to <input>'s
whereby legacy user agents would handle the inner content as fallback behavior
(into which a real <input type="checkbox"> would need to be placed). This seems
like a lot of unnecessary duplication to me--though others might argue.

Techniques 2 and 3 are virtually identical in the set of problems they'd need
to overcome. Basically, the OM for the <input type=checkbox> has 4 states today
for a pseudo-indeterminate checkbox:
State A: indeterminate + checked
State B: indeterminate + not checked
State C: not indeterminate + checked
State D: not indeterminate + not checked

The user experience for a true tri-state checkbox would need to cycle among
three of these four states. Consider two example cycles:
* D->A->C (repeat) - where the indeterminate state is more truthy than falsy
(for reads on the .checked IDL attribute)
* D->B->C (repeat) - where the indeterminate state is more falsy

Either cycle behavior may be desireable depending on the fallback scenario for
user agents that wouldn't support the new tri-state control.

A solution to the above cycle choice problem may be that the use of the
"checked" content attribute is taken as a hint to the UA to use either state A
(if checked is present) or state B (if checked is not present).

Also, other than the tri-state mode trigger, you'd want yet another content
attribute "indeterminate" (and corresponding "defaultIndeterminate" IDL
attribute) to hint the initial state of the UI to be indeterminate.

I think this is a great opportunity for an extension spec for integrating true
Tri-state checkboxes in HTML5.1. There are still a lot of potential issues to
work out, however.

Greg, are you interested in developing an extension spec for this feature?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 15 February 2013 01:49:28 UTC