W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2002

Re: Comment from CSS WG on HTML DOM draft

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
Message-Id: <1020978597.1010.11.camel@chacal>
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.

for the DOM WG.
[1] http://lists.w3.org/Archives/Public/www-dom/2002JanMar/0124.html

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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:10 UTC