Actually, the result of the checked
value in a click
handler is implementation dependent.
As I tested in several browsers, Chrome/Firefox/Safari/Opera will always return true in this case, but IE/Edge's behavior gets a bit weird if you keep clicking on that checkbox element.
And I found this paragraph in the spec, which might be a explanation of this inconsistency:
Note: During the handling of a click event on an input element with a type attribute that has the value "radio" or "checkbox", some implementations may change the value of this property before the event is being dispatched in the document. If the default action of the event is canceled, the value of the property may be changed back to its original value. This means that the value of this property during the handling of click events is implementation dependent.
But when I removed the preventDefault
statement, the results in IE/Edge are consistent with the other browsers, which confuses me.
So I don't think it is IE/Edge's intended behavior… Therefore I filed a bug on Microsoft Connect.
After all, if we presume Chrome's behavior to be standard-compliant, then the following might be a suitable explanation:
According to the HTML Spec, an input[type=checkbox]
element's checkedness is restored at the canceled activation process, which comes after the event handlers according to the Activation section. So during the execution of event handlers, the element's checkedness hasn't been restored yet.
(The spec doesn't explicitly state that canceled activation steps must come after all the event handlers; but it's easy to infer because otherwise there's no way to determine the event's canceled state)
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…