I apologize for duping http://bugs.jquery.com/ticket/769 but to hopefully redeem myself I will correct with a punchable plugin for those that need this in IE6: http://jsfiddle.net/eGgvw/13/

(function($) {
    var _append = $.fn.append;

    function getChecked( el ) {
        if ( el && el.jquery ) {
            return el.length == 1 && el[0].nodeName == "INPUT" && el[0].checked ? 
                el : 
                el.find('input:checked');
        }
        return $();
    }

    $.fn.append = function( arg ) {
        var chk = getChecked( arg ),
            ret = _append.apply( this, arguments );
        getChecked( arg ).removeAttr( 'checked' );
        chk.attr( 'checked', 'checked' );
        return ret;
    };
})(jQuery);

So far the closest to a feature detect I've gotten is this:

var div = document.createElement(div),
	input;

div.innerHTML = "<input type='checkbox' />";
input = div.getElementsByTagName( "input" )[ 0 ];

// IE6 actually sets checked to true here, and if it doesn't work, the
// appendChild doesn't clear the checked state - it should be fairly safe
input.click();
// interestingly - if you set input.checked = true it will work - odd eh?
// and maybe we should call this "appendResetsChecked"
jQuery.support.noAppendChecked = input.checked && !div.appendChild(input).checked;

http://jsperf.com/append-checked -- Might not be the right way to test the effects, but they don't seem that drastically bad here...

jQuery UI bug: http://bugs.jqueryui.com/ticket/3611

See also #1736, where someone was asking for the ability to preserve arbitrary expando properties. I think it's better to just deal with the critical ones like checked as you've done here.

But... doesn't this problem iron itself out if the attr rewrite sets the checked attribute when someone uses $(":checkbox").attr("checked", true); ? That way when the element is cloned and/or serialized it will reflect the current check state.

Of course, if someone uses $(":text").attr("value", "abc"); that would also change the serialized state of the element. I think that $(":text").val("abc"); should only set the dynamic state (value property) and leave the value attribute unmolested.

Nope, setting the checked attribute doesn't seem to be enough for IE6:

http://jsfiddle.net/AhhJh/

Replying to [comment:5 dmethvin]:

See also #1736, where someone was asking for the ability to preserve arbitrary expando properties. I think it's better to just deal with the critical ones like checked as you've done here.

Agreed

But... doesn't this problem iron itself out if the attr rewrite sets the checked attribute when someone uses $(":checkbox").attr("checked", true); ? That way when the element is cloned and/or serialized it will reflect the current check state.

Yeah, but thats not going to catch the actual user clicking on a radio to change it, unless you are suggesting they add a handler to every checkbox to set the attr to what it is, which could be a valid solution too...

Of course, if someone uses $(":text").attr("value", "abc"); that would also change the serialized state of the element. I think that $(":text").val("abc"); should only set the dynamic state (value property) and leave the value attribute unmolested.

The test case seems to work fine now: http://jsfiddle.net/timmywil/eGgvw/21/

#8060 is a duplicate of this ticket.

I didn't see the real problem before. This is a manip bug (IE6/7 can't handle keeping checked on appendChild).

Gnarf's duck punch above works to fix #8060. Patch incoming. http://jsfiddle.net/timmywil/MwtCW/8/

Timmywil's pull: https://github.com/jquery/jquery/pull/332

Duplicate of #8060.

Landing pull request 332. Appending disconnected radio or checkbox inputs and keeping checked setting Fixes #8060, #8500.

More Details:

• https://github.com/jquery/jquery/pull/332
• http://bugs.jquery.com/ticket/8060
• http://bugs.jquery.com/ticket/8500

Changeset: d274b7b9f7727e8bccd6906d954e4dc790404d23

#9470 is a duplicate of this ticket.