On Jan 19, 1:49 pm, 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.
That assertion is not backed up by evidence, you can only know what jQuery has done (or attempted to do) by reading the code. Your conclusion is based on Firebug's serialisation of the DOM in Firefox. Running the code in IE and checking the outerHTML property shows no checked attribute, so the conclusion there might be that attr() does change HTML attributes. While the lack of a standard for outerHTML might cause you to dismiss that result, it is significant in that it shows the futility of attempting to base generalised logic on examination of HTML attributes after the document has been loaded (especially if it has been modified by user interaction or script), or trying to guess what code is doing by observing attributes. There may be specific cases where examining attributes is useful, however it is unreliable as a general method, even in this very limited case. > >> 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 ? Setting the value of the checked property should reliably change the associated UI component (otherwise the browser is buggy), setting the related underlying HTML attribute may not have any visual effect even if the browser is fully compliant with the relevant standard. That is the whole point of using properties and not attributes. HTML attributes were intended to be read once when the document is first parsed, they were not expected to be changed dynamically. The dynamic nature of modern web pages is inconsistent with that principle. DOM properties are designed to be dynamic and used with scripts, they are more reliable and consistent across browsers. Therefore properties should be used unless there is a very specific need to use an attribute. [...] > >> 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) Using setAttribute to remove attributes is not recommended, the removeAttribute method should be used for that. Note that removeAttribute doesn't remove any attribute that has a default value, the attribute is just set back to its default. setAttribute is overloaded so that it adds and modifies attributes. It may remove attributes in some circumstances. Part of the problem with the W3C DOM specification is that it does not specify what setAttribute should do for an attribute that has no value (e.g. checked). Should the value on setting be ignored? If it has no value and the second parameter in the setAttribute call is Boolean false, should removeAttribute be called instead? > > doesn't update the display state of the > > checkbox.. changing the DOM property does it... get/setAttribute *may* change the checked property (and hence the displayed state of an element) depending on a number of factors. Describing all the various scenarios, or even a reasonable number of them, is beyond me. > > 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 data- attributes are part of the HTML5 draft, they are not part of any specification. Once HTML5 is a standard and widely supported, data-* attributes might be useful in general, however they are of limited value at present. >> .. adding a new method called > > `.prop()` and avoid overloading the `.attr()` method would be probably a > > better approach (in my opinion). No, that would be just as bad. I don't see the need for a method to access a property that can be read directly. Just forget about attributes, use properties only. And only use standard properties for DOM objects. > 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. The attr function does whatever it does, it probably exists solely for the purpose of being able to chain jQuery methods, I can't see any other use for it. > 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; No, they are properties, not attributes. There is no defaultChecked attribute, it doesn't exist. Browsers may or may not modify the related HTML attribute when a default* property is modified (note also that reading the inner/outerHTML properties has similar issues in this area). > 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. Your definition of synchronisation differs from mine. The default* properties are for one thing only: the value to use when a form is reset. Modifying the default* property may or may not affect the attribute value depending on the browser (and probably a number of other criteria such a quirks/standards mode and user interaction). > 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). The original HTML *attribute* values may or may not be lost, again, that is browser (and other factor) dependent. Since there are no default* attributes, it is up to the implementation what it does with the corresponding HTML attribute when those properties are changed, it is not specified anywhere. E.g. if a checkbox's defaultChecked property is set to true, there is nothing in the specification that says the HTML checked attribute must be set (or not). > I don't know if there are known problems using these "defaultXXXXXX" > DOM properties. Anybody have reasons against their usage ? Not in regard to their use, but the reason for using them should not be to (attempt to) modify the related HTML attribute. -- Rob -- 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]
