[whatwg] Form controls disabled IDL attribute and disabled state

[Ian Hickson]

On Sun, 12 Sep 2010, Mounir Lamouri wrote:
> 
> 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.
> 
> Feedbacks welcome :)
> 
> [1] if the fieldset has no disabled attribute, it still might be a child 
> of another fieldset which has a disabled attribute.
> 
> [2] some tricks might be to use query selector and check if the element 
> has the :disabled pseudo-class applying but that's only a workaround.

On Sat, 11 Sep 2010, Jonas Sicking wrote:
> 
> 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.

On Sat, 11 Sep 2010, Boris Zbarsky wrote:
> 
> Something like matchesSelector is an api on the element itself that does 
> what you want; do we really need another api for it?

Boris and Jonas make strong arguments here, so I haven't changed the spec.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'