- From: Philippe Le Hegaret <plh@w3.org>
- Date: 09 May 2002 11:09:56 -1000
- To: Bert Bos <bert@w3.org>
- Cc: WWW DOM <www-dom@w3.org>, w3c-css-wg@w3.org
The DOM WG reiterates its comment regarding the HTMLInputElement.indeterminate attribute [1] and decided to not add this attribute in DOM Level 2 HTML. The issue will stay as "active" in our list [2] and report while moving the draft to Candidate Recommendation. Philippe, for the DOM WG. [1] http://lists.w3.org/Archives/Public/www-dom/2002JanMar/0124.html [2] http://www.w3.org/Consortium/Process-20010719/groups.html#WGArchiveMinorityViews On Mon, 2002-04-15 at 09:04, Bert Bos wrote: > The CSS WG is disapointed with the DOM WG's decision and maintains its > opinion that "indeterminate" should be added. In detail: > > Checkboxes and radio buttons in user interfaces may not only be "on" > or "off", they may also be an in "indeterminate" state which means > that they are neither checked nor unchecked. Their state becomes > determinate when a user checks them. This is useful for example when > you have an option for which there is no reasonable default (for a > checkbox) or for a collection of radio buttons for which none should > be initially selected. > > This note documents a proposed addition to the HTML DOM that the CSS > working group believes would provide access to this state to content > authors. The state is already stylable using the :indeterminate > pseudo-class found in the Selectors specification. > > The proposal consists of the following addition to the > HTMLInputElement interface: > > attribute boolean indeterminate; > > The attribute is defined as follows: > > When the type attribute of the element has the value "radio" or > "checkbox", this represents whether the form control is in an > indeterminate state (neither checked nor unchecked), in an > interactive user agent. Changes to this attribute change the state > of the form control, but do not change the value of the HTML value > attribute of the element. > > An indeterminate control is neither checked or unchecked: although > the value of the checked attribute is not affected when the > indeterminate attribute is set, it is irrelevant. > > (A separate question is whether an indeterminate control should be > considered successful for the purposes of form submission, but that > doesn't affect the issue at hand.) > > As far as implementation status is concerned, we will note that there > are at least two different implementations. Both IE/Mac and IE/Windows > (which have separate DOM implementations) implement > input.indeterminate since version 4 (circa 1996). > > Thus the addition of this property should pose no problem for DOM > Level 2 HTML exiting CR since there are already two interoperable > implementations that have been shipping for quite some time. > > Mozilla (and Netscape 6.x) currently lacks this proposed property > because when Mozilla's DOM was implemented, the property was not > listed in the DOM specification. However, recent changes mean that the > support for indeterminate check boxes will be available soon, at least > internally (this support may not be exposed in the HTML DOM if the > "indeterminate" property is not added to the DOM spec). > > The DOM is also missing support for some other UI pseudo-classes, such > as :hover and :active, and for pseudo-elements, such as ::selection. > However, we do not think it would be wise to force this issue at the > moment. In our opinion, those issues are not yet mature. There is > ongoing work in the CSS working group to find solutions to these > problems. > > Adding .indeterminate to the DOM2 HTML spec is, in our opinion, a > reasonable thing to do for now, since there already exists several > years' worth of implementation experience.
Received on Thursday, 9 May 2002 17:09:59 UTC