On Jan 19, 4:49 am, Diego Perini <[email protected]> wrote: > On Wed, Jan 19, 2011 at 4:24 AM, Miller Medeiros > > > > <[email protected]> wrote: > > > On Tue, Jan 18, 2011 at 9:48 PM, Diego Perini <[email protected]> > > wrote: > > >> as you can see, the ".attr("checked", false)" may have changed a ton > >> of things on the element, but it surely didn't change any HTML > >> attribute on it. > > >> I repeat, false/true may work to switch on/of the visual check and the > >> properties bound to that behavior but that wasn't the point, was it ? > > >> If we can at least agree on the fact that ".attr()" does not change > >> any HTML attributes in this specific case it will be a step forward. > > >> -- > >> Diego > > >> PS: I also tried to remove the attribute using jQuery method > >> ".removeAttr()" cited in a previous posts but it doesn't seem to > >> remove the HTML attribute from the element :) > > > really good explanation Diego.. and I also confirmed that on Firefox > > setting/removing the attribute without jQuery (using > > setAttribute/getAttribute) doesn't update the display state of the > > checkbox.. changing the DOM property does it... > > > for attributes like "data-myawesomedata" $.attr() does really update and > > return the attribute value... so this method does have different output and > > functionality depending on the use-case.. adding a new method called > > `.prop()` and avoid overloading the `.attr()` method would be probably a > > better approach (in my opinion). > > Exactly, that's why I have repeatedly underlined that behavior with > the specific "checked" property. As you noticed this isn't true for > all the attributes. > > That's maybe one of the reasons why it is impossible to find a generic > explanation of what ".attr()" does. Let's say that this fact affect > the most when handling form controls. > > I maybe didn't completely understand the question initially but if the > task was to change both the property value AND the attribute value > synchronously I believe the following should have been used: > > inp.defaultChecked = false; > inp.defaultChecked = true; > > These properties (and defaultValue, defaultSelected for input and > select box) are the ones in charge of the dynamic synchronization of > UI events and dynamic DOM values. >
Answering to myself here to amend some incorrect statement I made. After a few test writing to these "default*" properties I have to rectify my assumptions and observations here. Not a cross-browser behavior. They may be useful for reading the initial state of the control when it was parsed (as a workaround for IE bugs) but as RobG said it is better not touch the "default*" values especially not as a mean to overwrite the HTML attribute, no need to do this if only DOM properties are used. -- Diego > Be aware though that by overwriting those properties the original HTML > values served in the page are lost (so one should save them before > destroying if needed). > > I don't know if there are known problems using these "defaultXXXXXX" > DOM properties. Anybody have reasons against their usage ? > > -- > Diego > > > cheers. > > > -- > > To view archived discussions from the original JSMentors Mailman list: > > http://www.mail-archive.com/[email protected]/ > > > To search via a non-Google archive, visit here: > >http://www.mail-archive.com/[email protected]/ > > > To unsubscribe from this group, send email to > > [email protected] > > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
