#7594 closed bug (invalid)
Html() is not outputting Checked attribute
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | low | Milestone: | 1.5 |
Component: | manipulation | Version: | 1.4.4 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
I'm not sure whether this is intended behaviour for some cross browser reason. But when you call .html() on an element that contains a checkbox with it's checked attribute set to true, the resulting html does not contain the checked setting.
See code example in link below: http://jsfiddle.net/mNvYG/
I would have expected the second alert to display '<input type="checkbox" checked>'
Change History (9)
comment:1 follow-up: 3 Changed 12 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:3 Changed 12 years ago by
Replying to snover:
Thanks for the report, but this is not a jQuery bug. The checked property is not the same as the checked attribute.
.attr
sets the property value, which is not reflected in the DOM.
Could you possibly provide a better explanation? I understand that when you set a property in jQuery it is not setting the attribute until it gets added to the DOM. However, when you call .html() on the jQuery all other attributes set through jQuery properties are included in the resulting html string. Should the html() call not reflect the current state of the element so that you can recreate it?
It also can cause inconsistencies between the jQuery properties and the outputted html. See this example I've put together (http://jsfiddle.net/3q2fm/).
Is there some particular reason why checked is treated in this way?
Thanks
Iain
comment:4 Changed 12 years ago by
jQuery’s .attr
currently looks to see if a DOM HTML property exists on the object, and if it does will set that property instead of calling setAttribute
. Very convenient and usually faster, but an occasionally undesired side-effect of this behaviour is that the attributes NamedNodeMap does not get updated when a DOM HTML property is changed. (For reference, attributes
is the array-like structure that stores the actual attributes for an element that form its serialized representation.) I think that’s about as good an explanation as any.
comment:5 Changed 12 years ago by
Thanks for the response.
So in summary, for speed benefits in jQuery we can't always rely on .html() being an accurate representation of the object.
comment:6 Changed 12 years ago by
The takeaway would be that the DOM HTML spec does not say that its interfaces should cause any modification to the portions of the Element object that are used for serialization, and indeed they do not.
This method’s behaviour will change significantly in 1.5 to stop doing this.
comment:7 follow-up: 8 Changed 12 years ago by
I think we should consider of making 'checked' attribute for checkboxes as special cases.
Compare two approaches
var html = '<input type="checkbox" checked="checked">';
and
var html = $('<p>').append($('<input>', {type: 'checkbox', checked: 'checked'})).html()
I would prefer to use second approach because I think that string manipulation is not good enough :)
But because of this 'issue' I cannot achieve expected behavior.
comment:8 follow-up: 9 Changed 12 years ago by
Component: | unfiled → manipulation |
---|---|
Priority: | undecided → low |
Replying to mnaoumov:
I don't understand. You can do both of those. http://jsfiddle.net/timmywil/mNvYG/1/
comment:9 Changed 12 years ago by
Replying to timmywil:
Replying to mnaoumov:
I don't understand. You can do both of those. http://jsfiddle.net/timmywil/mNvYG/1/
Try to change on your jsfiddle example jQuery version from 'edge' to '1.5.1'. You will see the issue. On my project I'm using 1.5.2 and having the same issue.
Thanks for the report, but this is not a jQuery bug. The checked property is not the same as the checked attribute.
.attr
sets the property value, which is not reflected in the DOM.