You can clone with
HTTPS or Subversion.
The new nightliy build Jquermobile don't set the horizontal grouped radio inputs to checked.
thanks for the nice work.
Can you post a jsbin or jsfiddle illustrating the issue you're seeing? These seem to toggle:
Year they toggle, but shouldn't the underlying input tag get a checked html - attribute?
confirmed, running into the same issue, no need for jsfiddle, http://jquerymobile.com/demos/1.0/docs/forms/radiobuttons/ shows similar behavior...
Original input never gets checked="checked"
Is this on every browser on just a specific one? Looking into this now.
Fixes #2553 — Addresses issue where underlying checkboxes/radio butto…
…ns were not being updated when enhanced buttons were clicked.
I'm not positive, but I think this was configured better before this change - not sure it was actually a bug. While it's confusing that the checked attribute wasn't updating, I think that's actually expected behavior for properties like "checked", in which the attribute delivers an initial property value of the element, but after that, we'd update the property rather than the attribute. With that original system in place, to check the value, you could use prop() instead of attr()
We switched from attr() to prop() when jQuery core added the method, since in theory, prop should be used for manipulating properties like this after load. Now that it's using attr() again, I don't think the input's actual checked property is being updated anymore, and the new issue #3670 suggests as much. Setting the attribute may be sufficient for form submission
(did we test that?), but I'm not sure it digs in to set the property itself.
By using attr() to change the value, jQuery's ":checked" selector doesn't seem to find the property, but "[checked]" does, since we're updating the attribute.
I noticed we still have the prop()-based version in the code, commented out beneath it.
@wilto - I think this was a pull you might have approved... Maybe you could chime in on why we needed to change this back to attr()? I wonder if the following is the change we might need to make:
input.prop( "checked", inputtype === "radio" && true || !input.prop( "checked" ) );
(before, in the commented-out code, the second call to prop there was using attr() instead, which may have been the real cause of the bug originally. maybe...)
Here's the commit that caused the regression. karol-f@f269788
This one works fine with latest, going to the docs pages referenced
Scrolling to the bottom and selecting the last radio button in the horizontal group and
Will get you true.
If this really closed ? With Chrome 19, Opera 12 and Firefox Nightly on http://jquerymobile.com/demos/1.1.0/docs/forms/radiobuttons/ I still have this problem... Look at the button, neither
List, Grid or Gallery's original input get checked.
Unless I've misunderstood your comment:
You're right, $('input[name=radio-view]:checked') returns the selected item. What confuses me is that the DOM do not reflect this state (where is the checked attribute?). Also, and consequently, $('input[name=radio-view][checked]') do not return this item.