[whatwg] Form controls disabled IDL attribute and disabled state

On Sat, Sep 11, 2010 at 3:57 PM, Mounir Lamouri
<mounir.lamouri at gmail.com> wrote:
> Hi,
>
> With HTML4 (at least before fieldset.disabled), form controls disabled
> IDL attribute was a simple way to set and get the disabled state because
> the disabled state and the disabled content attribute were exactly the
> same thing.
>
> Now, with fieldset.disabled, disabled IDL attribute has no longer the
> same meaning. It's now only reflecting the content attribute and not the
> disabled state. Nothing in the API let the author knows the disabled
> state so the only solution is to look at the entire parent chain until a
> fieldset with the disabled attribute is found [1].
>
> I can understand why when getting the disabled IDL attribute, this is
> not returning the state but the content attribute but I think there is a
> lack in the API and it might be nice for authors to have a simple way to
> know the state of the element [2]. This could be done with the IDL
> attribute returning the state instead of the content attribute or
> another attribute returning the state.

First of all, I think setting the .disabled IDL has to map to setting
the content attribute. I can't think of any other sane behavior (other
than not having a setter at all, but that wouldn't be backwards
compat)

Second, it seems confusing to me to have the getter and setter "not
match". I.e. to get vs. set entirely different things. This results in
weird situations like

foo.disabled = false;
x = foo.disabled;
// x is now true

and

foo.disabled = !foo.disabled
// This might be a no-op

The result of these two statements is that I think that the spec for
.disabled should not be changed.

This leaves the question of if we should expose the computed disabled
state thorough some other property. I don't really feel strongly about
this, but as with any feature, we should ask what the use case is.

/ Jonas

Received on Saturday, 11 September 2010 17:36:50 UTC