ok, thanks It's important because as the users/developers of Mootools upgrade their framework same use functionality should exist unless otherwise documented as with the many new features of mootools 1.3
Gafa On Nov 30, 5:15 pm, Sean McArthur <[email protected]> wrote: > So, I was largely wrong in whats happening behind the scenes. checked is > actually handled by setting the property directly, but defaultChecked is > also set in the constructor for IE, and defaultChecked was calling > setAttribute with the string false. I've pushed a fix, but note that my > other statements are still correct: passing null will call removeAttribute, > or not set either checked nor defaultChecked. > > On Tue, Nov 30, 2010 at 12:39 PM, Sanford Whiteman < > > [email protected]> wrote: > > > But Gafa's point is that it used to support booleans and abstracted > > > dot-property, then changed. > > > And IMO the clearest parallel to > > > name : value > > > is dot-property, since the same format accounts for both cases, while > > setAttribute/removeAttribute would be better abstracted something like > > > name : value > > !name > > > which is obviously not supportable using object literals. The null is > > not something that has much place in DOM and I think it's strange to > > encourage it in frameworkland. As you probably know, even though > > within browsers set(value,null) ~= remove(value), this is only by > > happy accident and *not* standard (it's deprecated by individual > > browser vendors, but isn't even in the spec enough to be deprecated). > > When you more clearly follow the DOM spec, there would be no obvious > > way for set(value,null) to be coerced into remove, since > > set(value,null) could just as well be coerced to set(value,"null") > > which is not the same as remove. > > > BTW, I do see the dot-property emulation as working in IE8/Moo1.3, > > though not in IE7/Moo1.3! > > > -- S.
