Re: Comment from CSS WG on HTML DOM draft

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