This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26226 - Clarify "A form control is disabled…"
Summary: Clarify "A form control is disabled…"
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks: 26744
  Show dependency treegraph
 
Reported: 2014-06-27 21:19 UTC by contributor
Modified: 2014-09-06 20:08 UTC (History)
5 users (show)

See Also:


Attachments

Description contributor 2014-06-27 21:19:54 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html
Multipage: http://www.whatwg.org/C#enabling-and-disabling-form-controls:-the-disabled-attribute
Complete: http://www.whatwg.org/c#enabling-and-disabling-form-controls:-the-disabled-attribute
Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html

Comment:
Clarify "A form control is disabled…"

Posted from: 87.64.226.18 by ms2ger@gmail.com
User agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
Comment 1 Ms2ger 2014-06-27 21:20:50 UTC
<Hixie> Ms2ger: [form controls] are disabled if they have a disabled attribute set, where "disabled attribute" is specifically "attr-fe-disabled", which only some elements can have setµ
<Ms2ger> Hixie, that's pretty obscure
<Hixie> Ms2ger: no disagreement from me there :-)
<Ms2ger> Hixie, I think that's worth a note, at least
<Hixie> Ms2ger: absolutely agreed
<Hixie> Ms2ger: file a bug :-)
Comment 2 Garrett 2014-07-15 22:19:23 UTC
+1 

There is no property to determine if a form control is actually disabled. There should be.

HTML5 defines new jargon, "actually disabled", to describe controls that are either (a) disabled or (b) descendants of disabled fieldsets. 

Instead, HTML5 should define "enabled" to describe whether or not a control can be interacted with and this "enabled" state descriptor should then be exposed to the DOM, as `control.isEnabled`.


See also:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jul/0059.html
Comment 3 Garrett 2014-07-15 22:25:16 UTC
See also:

http://www.whatwg.org/specs/web-apps/current-work/#concept-fe-disabled

Propose rewording:

A form control is disabled if its disabled attribute is set, or if it is a descendant of a fieldset element whose disabled attribute is set and is not a descendant of that fieldset element's first legend element child, if any.


To:

A form control is enabled unless any of the following are true:
 * its disabled attribute is set
 * it is a descendant of a fieldset element whose disabled attribute is set and is not a descendant of that fieldset element's first legend element child, if any.
Comment 4 Ms2ger 2014-07-16 08:27:59 UTC
Garrett, please file another bug.
Comment 5 Ian 'Hixie' Hickson 2014-09-04 22:22:05 UTC
Let me know if it's not sufficient.
Comment 6 contributor 2014-09-04 22:22:22 UTC
Checked in as WHATWG revision r8746.
Check-in comment: Try to clarify 'form control is disabled'.
http://html5.org/tools/web-apps-tracker?from=8745&to=8746
Comment 7 Garrett 2014-09-05 05:33:23 UTC
(In reply to contributor from comment #6)
> Checked in as WHATWG revision r8746.
> Check-in comment: Try to clarify 'form control is disabled'.
> http://html5.org/tools/web-apps-tracker?from=8745&to=8746

Why is naming things one of the hardest part in programming and API design?

While your proposed verbiage addresses the problem of attr-fe-disabled vs any random attribute named "disabled", I think it is not well-written and that it leaves a glaring problem which came up in comment 2.

I propose that defining these eligible-for-success enabled controls by using "disabled" and "actually disabled" horribly confusing to the listener. Try describing this situation without overloading. Here's a start: "A form control is enabled unless..."

I'm not a great writer, but simply looking at your rewording, I think it can be better.


You have:
The <code data-x="attr-fe-disabled">disabled</code> attribute is a conforming attribute on this element, and is specified on this element (regardless of its value).</li>

<li>The element is a descendant of a <code>fieldset</code> element whose <code
data-x="attr-fieldset-disabled">disabled</code> attribute is specified, and is <em>not</em> a descendant of that <code>fieldset</code> element's first <code>legend</code> element child, if
any.</li>


Better:
Its <code data-x="attr-fe-disabled">disabled</code> attribute, if conforming, is specified (regardless of any value or lack thereof).</li>

<li>It is a descendant of any <code>fieldset</code> element whose <code
data-x="attr-fieldset-disabled">disabled</code> attribute is specified, and is <em>not</em> a descendant of that <code>fieldset</code> element's first <code>legend</code> element child, if any.</li>


I expect most people to be confused by trying differentiate "disabled" from "actually disabled". Specs shouldn't be riddles.

A similar example of overloaded terminology exists with ECMAScript's use of `prototype`, used to describe the `prototype` property given to all user defined and many built in functions and `[[Prototype]]`, which defines object internal prototype property. Explaining that user-defined functions have both a prototype and a [[Prototype]] confuses students, who do sincerely try to understand ECMAScript spec. Curious, sharp students, shouldn't be punished by badly-chosing technical language.