- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 8 Dec 2010 01:05:35 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 7 December 2010 17:05:35 UTC