123836 - Implement .indeterminate property on checkboxes

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, enhancement)

Description

[Hixie (not reading bugmail)]

It would be rather useful if <input type="checkbox"> and <input type="radio">
controls could support tri-state mode, triggered by the "indeterminate" DOM
property as defined by Microsoft: 

http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/indeterminate.asp
http://msdn.microsoft.com/workshop/browser/mshtml/reference/ifaces/inputelement/indeterminate.asp

Comment 1

[John Keiser (jkeiser)]

DOM WG doesn't want this, so we'll have to put it in nsIDOMNSHTMLInputElement. 
When XBL form controls are turned on, this will be just as easy as setting the
:checked property will.  Setting to 1.1 since that's the milestone-after-XBL.

Comment 2

[David Fraser]

What's the status on this ... would it have to be done using XBL?

Comment 3

[Weston Ruter]

"The official feedback on DOM Level 2 HTML is a request to add an 'indeterminate' property to Interface HTMLInputElement."

"In November 2000, DOM Level 2 HTML was delayed for backward compatibility reasons and our intent is to capture the current practice in several implementation, which is not the case for indeterminate. Only IE implementations are supporting this indeterminate feature for the moment. The TriState implementation does support indeterminate property but it is not equivalent to the one in IEs. So, even if other implementation are going to implement indeterminate in the future, we prefer not to add this new feature for the moment. This certainly needs to be on the list for an XForms API at some point."

<http://www.w3.org/2001/12/DOM-Level-2-issues>

Comment 4

[Michael Ventnor]

HTML 5 got this property newly added to it. We might as well try it out, it seems like it could add nice polish to web apps that use treefuls of checkboxes.

Comment 5

[Michael Ventnor]

Attachment: Patch

This adds backend support for the property, plus adds drawing support for generic widgets and GTK widgets. Mac and Windows can be done later.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

+[scriptable, uuid(b92b725e-b75a-49a0-b6f9-e16bc4bfa3de)]
 interface nsIDOMHTMLInputElement : nsIDOMHTMLElement

nsIDOMHTMLInputElement is frozen so you can't do this. Add to nsIDOMNSHTMLInputElement instead.

+PaintIndeterminateMark(nsIRenderingContext& aRenderingContext,
+                       const nsRect& aRect)
+{
+  // Drawing a thin horizontal line in the middle of the rect.

Why is this the right thing to do?

+  nsCOMPtr<nsIDOMHTMLInputElement> elem(do_QueryInterface(mContent));
+  PRBool retval = PR_FALSE;
+  elem->GetIndeterminate(&retval);

Probably best to do a null check here in case our content is an unexpected type.

Otherwise looks good. When you post a new patch, ask jst for review on the content part.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Are we out of bits in the bitfield?  If not, why are we adding a new member?

I'd really like to see a diff with more context and -p here.  In fact, it might be worth setting your mq to always do that...

Comment 8

[Michael Ventnor]

We discussed these IRL :) but I'll put them in a comment anyway.

(In reply to comment #6)
> +PaintIndeterminateMark(nsIRenderingContext& aRenderingContext,
> +                       const nsRect& aRect)
> +{
> +  // Drawing a thin horizontal line in the middle of the rect.
> 
> Why is this the right thing to do?

This is what Mac and most GTK themes do. Windows seems to change their appearance of tristate checkboxes in each version. Plus its easy to do.

> +  nsCOMPtr<nsIDOMHTMLInputElement> elem(do_QueryInterface(mContent));
> +  PRBool retval = PR_FALSE;
> +  elem->GetIndeterminate(&retval);
> 
> Probably best to do a null check here in case our content is an unexpected
> type.

The other existing function GetChecked() doesn't do that. I don't think the content will ever be an unexpected type.

Comment 9

[Hixie (not reading bugmail)]

Oops, in HTML5 I only made it apply to checkboxes. Does it apply to radio buttons too?

Comment 10

[Michael Ventnor]

No.

Comment 11

[Michael Ventnor]

Attachment: Patch 2

Fixes comments.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 355667 [details] [diff] [review]
Patch 2

   nsRefPtr<nsDOMFileList>  mFileList;
+
 };
 
Lose the blank line

Comment 13

[Boris Zbarsky [:bzbarsky]]

So the indeterminate state doesn't affect :checked matching on checkboxes/radios?  That is, they match based on their checked state no matter what the indeterminate state is?

Comment 14

[Michael Ventnor]

Correct. According to HTML5 (and MSDN, God help it), indeterminate only affects the appearance of the control and the checked state is toggled independently.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I'm not talking about the "checked state" in terms of DOM state but in terms of CSS style matching.  Should the CSS :checked selector match indeterminate controls?

Comment 16

[Michael Ventnor]

I don't think so. The way the spec reads, it says the indeterminate attribute should not affect anything other than just the appearance of the control.

Comment 17

[Boris Zbarsky [:bzbarsky]]

I'm not sure that makes sense to me, especially since the whole point of styling _is_ appearance.

Comment 18

[Hixie (not reading bugmail)]

We can say that :checked doesn't apply if :indeterminate applies. I haven't defined how the pseudos match HTML5 stuff yet.

Comment 19

[Michael Ventnor]

Attachment: Patch 3

Remove that space.

Comment 20

[Johnny Stenback (:jst)]

Comment on attachment 355703 [details] [diff] [review]
Patch 3

r=jst.

Are there bugs filed on doing the Mac and Windows drawing part of this changed?

Comment 21

[Michael Ventnor]

Attachment: Updated to tip

Not that I'm aware of. I might file them later.

Comment 22

[Michael Ventnor]

Oops, that patch got the tests dropped from it.

Comment 23

[Michael Ventnor]

Attachment: Update to tip with tests

Comment 24

[cajbir (:cajbir)]

Pushed to mozilla-central:
http://hg.mozilla.org/mozilla-central/rev/41d6bf675366

Comment 25

[Sylvain Pasche]

Just curious, why do the test pass on Windows and Mac if that's not implemented there yet and the manifest does not exclude these platforms?

Comment 26

[Markus Stange [:mstange]]

The test turns off native theming using -moz-appearance: none, so it falls back to the cross-platform rendering.

Comment 27

[Sylvain Pasche]

ok, makes sense now. Thanks for the explanations.

Comment 28

[Sylvain Pasche]

Attachment: testcase

Testcase showing various checked/indeterminate/enabled variations on checkboxes and radios.
Firefox/IE/Safari Mac seem to agree on the rendering here, except Safari on Windows which renders a checkbox with checked+indeterminate the same way as a non-indeterminate checked checkbox (looks like a bug).

Comment 29

[Yet Ding]

Is this only a DOM attribute (settable in Javascript) or a content attribute (settable in the HTML tag)?

The original IE implementation has it as a content attribute with the nonstandard indeterminate="true"/"false" syntax. 

HTML5 only defines it as a DOM attribute, not as a content attribute:
http://www.w3.org/TR/html5/forms.html#the-input-element
http://www.w3.org/TR/html5/forms.html#dom-input-indeterminate

Comment 30

[Michael Ventnor]

DOM only.

Comment 31

[Eric Shepherd [:sheppy]]

While the CSS :indeterminate is documented, we need to document the input element's support for this too.

Comment 32

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Do we handle the indeterminate state on checkboxes inside a tree/listbox differently? When I try to get the value of the restore column of the listbox in the about:sessionrestore page, I get true, false, and 0.

Here an example:

var elem = document.getElementById("tabList");
var restore = elem.view.getCellValue(0, tree.columns.getColumnAt(0))

If any tab under a window should not be restored, 'restore' will be 0.