On 1/18/11, RobG <rg...@iinet.net.au> wrote:
>
>
> On Jan 19, 6:03 am, fernando trasvina <trasv...@gmail.com> wrote:
>> On Jan 18, 2011, at 12:15 PM, Miller Medeiros wrote:
>>
>>
>>
>> > On Tue, Jan 18, 2011 at 9:47 AM, Diego Perini <diego.per...@gmail.com>
>> > wrote:
>>
>> >    $('#my-check-box').attr('checked', true);
>>
>> > will confuse users into believe that "false" in the above statement is
>> > needed to achieve the opposite effect of unchecking the element
>> > attribute, which is not the case. Instead a "removeAttr()" will be
>> > needed to achieve that effect (with UI live attributes like
>> > "checked").
>>
>> > if you pass false to the checked attribute it will uncheck it.. (it
>> > probably calls removeAttr internally)
>>
>> What i think it does (actually from making several tests)
>
> The code is publicly available, no need to depend on empirical
> evidence.
>
>> when you create a checkbox and get the checked property you obtain false
>> if you click on it and ask for checked attribute you obtain true
>
> That sums up the issue with jQuery's attr function - it mixes up
> attributes and properties to the extent that it is difficult to tell
> which they are using unless you read the code.
>
Yes.

> There is rarely a need to use attributes anyway, particularly as IE's
> implementation of get/setAttribute is broken. DOM properties are more
> appropriate in the vast majority of cases, not least because they are
> more consistent across browsers and simpler to access.
>
Yes.

> E.g. what do you expect the following to show?
>
>   <input type="button" value="Test checked" onclick="
>     alert( !!document.getElementById('cb0').getAttribute('checked'));
>   ">
>   <input type="checkbox" id="cb0" checked value="foo">
>
> You may be surprised to see boolean false in Firefox even though the
> checked attribute is present, because the value of the checked
> *attribute* is an empty string, which type-converts to boolean false.
> IE shows true.
>
Running that example:
IE8, the checkbox' checked attribute value is "checked".
IE9, it is ""
IE (any) in quirks mode, it is `true` (boolean, not string).

> Similarly:
>
>   <input type="button" value="Set checked" onclick="
>     var el = document.getElementById('cb1');
>     el.setAttribute('checked', false);
>   ">
>   <input type="checkbox" id="cb1" value="foo">
>
> Will check the checkbox in Firefox (because the supplied value is
> irrelevant) but not in IE. It is because of these types of quirks and
> inconsistencies that get/setAttribute should be avoided and DOM
> properties used.
>

IE8, IE9 checks the checkbox
IE 7 and below, IE quirks mode: does not check checkbox

The rexplanation for that is that IE7 and below treat attributes as
properties. IE8 got better, but had a few wrinkles. IE9 has shaped up
quite well.

> Once you start using properties, there is no need for methods like
> attr. The only reason to use it at all is for non-standard attributes,
> where some browsers require get/setAttribute as they will not create
> equivalent DOM properties from inline HTML.
>

Some URL based attributes, in various browsers, and tabIndex in IE.
Though totally agreed on point: Genericized attribute reading
functions are Overkill. Sounds nice, but can't cover all of those
cases.

> However the use of non-standard attributes (and "expando" properties)
> in HTML should be avoided, so again, no need for get/setAttribute.
>
>
>> now passing any JavaScript falsy value to checked will uncheck the
>> checkbox and getting later the value you will get a false
>
> Except that the string "false" is not falsy (replace Boolean false
> with the string "false" in the setAttribute test above and all
> browsers will check the checkbox), a common cause of confusion. The
> checked attribute has no value, its presence or absence is the key.
> The checked property always has a Boolean value and so is much simpler
> to use.
>
>
>> same occurs when passing any truthy  value you will get true when getting
>> the value later
>>
>> removing the checked attribute has no effect on the input
>
> Depends on the browser and what the user has been doing. Removing the
> *attribute* unchecks a checkbox in Firefox if the user hasn't modified
> it first, but not in IE. Whether or not you can remove the property is
> moot. It reinforces the advice not to mess with attributes as the
> results are unreliable, use DOM properties.
>
>   <input type="button" value="Remove checked" onclick="
>     var el = document.getElementById('cb2');
>     el.removeAttribute('checked');
>   ">
>   <input type="checkbox" checked id="cb2" value="foo">
>
>
>> so from this i would recommend to use true or false for checked attribute
>> to keep things clear
>
> I would not.
>
RIght. Use the checked property instead.

Thanks for the testcases and explanations, Rob.

>>
>> correct me if i am wrong pls.
>
> Do not use element attributes in code for reasons stated above, always
> use DOM properties.

Yes. And when they fail, post up a test case, browser results. It's at
worst a matter of feature testing the problem and coming up with a
workaround; at best, finding a different way of doing it that requires
no feature test.
-- 
Garrett

-- 
To view archived discussions from the original JSMentors Mailman list: 
http://www.mail-archive.com/jsmentors@jsmentors.com/

To search via a non-Google archive, visit here: 
http://www.mail-archive.com/jsmentors@googlegroups.com/

To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com

Reply via email to