This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html Multipage: http://www.whatwg.org/C#radio-button-state-(type=radio) Complete: http://www.whatwg.org/c#radio-button-state-(type=radio) Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html Comment: "The canceled activation steps consist of setting the element's checkedness to false." needs to also revert the checkedness state of other radio buttons that were affected. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2917 Posted from: 90.230.218.37 by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.76 Safari/537.36 OPR/21.0.1432.31 (Edition Next)
Also see https://www.w3.org/Bugs/Public/show_bug.cgi?id=25258 and consider if the element or the other affected radio button changes type or changes name or changes form owner or home subtree...
What Firefox is doing is just setting the checkedness of the previously-checked radio button, if any, or else just unsetting the target. What Chrome is doing involves checking the types. Firefox seems simplest.
(In reply to Ian 'Hixie' Hickson from comment #2) > What Firefox is doing is just setting the checkedness of the > previously-checked radio button, if any, or else just unsetting the target. I guess that works.
https://github.com/w3c/web-platform-tests/issues/994
Checked in as WHATWG revision r8704. Check-in comment: Change how we define what happens when radio buttons are clicked but the event is canceled http://html5.org/tools/web-apps-tracker?from=8703&to=8704