Would like to have this "not disabled state exposed to the DOM. The proposal is for a new property, `isEnabled`.

http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jul/0060.html

What's the problem that this proposal is solving?

Problem 1: The duplicitous meaning of "disabled" (1) the control's disabled attribute is set, (2) the control's disabled attribute is not set, but the control is a descendant of a fieldset element whose disabled attribute is set but is not a descendant of that fieldset's first legend element child.

Problem 2: To allow program code to determine form control ineligibility for success.

Problem 3: to determine form control inability to be interacted with.

Problems 2 and 3 include the situations of (a) descendant controls of any OPTGROUP or FIELDSET whose disabled attribute is set (but not a descendant of that FIELDSET's first legend element child). These controls cannot be interacted with, are ineligible for success, and this is hard to determine in code because these controls do not have a `disabled` attribute set.

What are the use cases for 2 and 3?

1) To allow program code to determine form control ineligibility for success and not send control's name/value pair in an Ajax request if it is disabled.

2) The program needs to know if a particular action should taken depending on the state of a form control. Say that action is "show a message" a checkbox is checked and a text input is blank and both the checkbox and the input are enabled and not readonly (interactible + eligible). 

(#2 is a gross oversimplification of the previous app I worked on).

Use case 1 seems like it'd be handled by just submitting the form via XHR (using the FormData interface). I don't see why you'd need to examine the controls individually. Also, presumably the code knows which controls are disabled, since that's under the control of the code.

I don't understand use case 2. Can you elaborate?

#1) Last project, change requirements could not easily be fulfilled by restructuring the code to send a form through an XHR and providing a fallback. It was not an option to replace the library that was being used. They had built the POST body from the form and it needed to be tweaked.

#2) Need to determine form control ineligibility for success. The confusion is that the disabled property doesn't reflect the disabled state. But .matchesSelector(":disabled"), where supported, does (though not so obvious and requires some thought). I know that I didn't elaborate case #2 as you asked. Here is why:

If a checkbox is disabled, the program doesn't do X. Modifying the code to have the checkbox and some other controls in an enclosing fieldset seemed ideal; there was a case where disabling that would-be fieldset made sense and could have potentially simplified application logic. But then subsequent checks to that checkbox's or any of the controls' `disabled` might find that those controls' respective `disabled` property was false no matter what and did not inherit the ancestor FIELDSET's disabled property; just the disabled state. 

So then the code that checked to see if the control was disabled would have had to first check the `disabled` property of the control and then check up the ancestor tree to find if there is any disabled FIELDSET.

* [whatwg] Form controls disabled IDL attribute and disabled state
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-September/028501.html

(In reply to Garrett from comment #7)
> #1) Last project, change requirements could not easily be fulfilled by
> restructuring the code to send a form through an XHR and providing a
> fallback. It was not an option to replace the library that was being used.
> They had built the POST body from the form and it needed to be tweaked.
> 
> #2) Need to determine form control ineligibility for success. The confusion
> is that the disabled property doesn't reflect the disabled state. But
> .matchesSelector(":disabled"), where supported, does (though not so obvious
> and requires some thought). I know that I didn't elaborate case #2 as you
> asked. Here is why:
(Here is the reason you asked for)


> 
> So then the code that checked to see if the control was disabled would have
> had to first check the `disabled` property of the control and then check up
> the ancestor tree to find if there is any disabled FIELDSET.
> 

(or use matchesSelector)

Sorry about edit.

(In reply to Garrett from comment #7)
> #1) Last project, change requirements could not easily be fulfilled by
> restructuring the code to send a form through an XHR and providing a
> fallback. It was not an option to replace the library that was being used.
> They had built the POST body from the form and it needed to be tweaked.

The solution there is to fix the change requirements, not change the entire industry's standard and get multiple vendors to write new code.


> If a checkbox is disabled, the program doesn't do X.

I don't understand. What is X? Surely whether the program does something or not should be predicated on whether a checkbox is checked, not whether a checkbox is disabled. What disabled the checkbox? Just use the same logic to know whether to do X or not.

Looking back over this bug, we seem to have meandered away from the original report.

I still don't understand the point of the original report. The text around there has changed; it now reads:

| A form control is disabled if any of the following conditions are met:
| 
| * The element is a button, input, select, or textarea element, and the disabled 
|   attribute is specified on this element (regardless of its value).
| * The element is a descendant of a fieldset element whose disabled attribute is 
|   specified, and is not a descendant of that fieldset element's first legend
|   element child, if any.

If that is now satisfactory, please describe the problem with the current text such that I can address it. Thanks.