Why does preventDefault on checkbox click event returns true for the checked attribute?

Question

I am just curious and need some explanation on the following situation.

Let\'s say i have an input element of type checkbox with an eventlistener attached to it, lis

Answer 1

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)