On Jan 19, 8:29 am, RobG <[email protected]> wrote: > 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. >
The interest was only about the outcome of that jQuery code, not how it would do or attempt to do that internally. Though, it is clear that inspecting the code would give more insights. I was trying to make a point about jQuery ".attr()" effects with dynamic properties in the realm of standard browsers. > 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. You didn't read atop of my message, for this example Internet Explorer was excluded exactly for his different behaviors, to discern problems one by one. And to be correct in IE8 standards mode it doesn't change the HTML attribute either ! Only in "compatibility mode" and so maybe in older IE. Are you saying that I should not trust Firebug serialization and instead trust Internet Explorer "outerHTML" serialization ? You assume my conclusions were based only on Firebug serialization, I just didn't want to mix standard Javascript with jQuery code in that example. I actually inspected the outcome/result also using the "getAttribute()" and using "querySelectorAll()" DOM methods with the same results both on Firefox/Safari/Chrome. I didn't do any test in Opera, but I doubt results could be any different from those obtained in Firefox. > 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. I was referring to ".removeAttr()" method in jQuery. > > 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. > I agree with your suggestion, it will greatly ease development. However if the ".attr()" method will remain in jQuery I believe it would be correct to name it appropriately. > > 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 You are misunderstanding, or I didn't explain well enough. I absolutely haven't said "defaultChecked" is an HTML attribute. What I said is that I observed that changing the "defaultChecked" property of checkbox controls has the effect of changing both the "checked" attribute and the "checked" property of the element. Though you are correct, these are only my observations, there is no standard explaining or enforcing this exact behavior, so it may depend on browsers implementations. In reality most browser agree about this but maybe you can name a browser that does not follow this behavior, so I can try it out. > 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. > When writing to the "default*" property values, whatever the reason and the objective is, there is no way that I known to avoid also modifying HTML attribute and related DOM properties. -- Diego > -- > 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]
