I encountered some surprising behaviour today, whereby in a form reset event callback, the values do not appear to actually have been reset by the time the callback fires.. This seemed very strange to me..

A timeout as short as a break in flow enables access to the [expected] reset value, but without this, the input's value in the reset callback is the value before the form has actually been reset.

In the following reduced test case, if I check the 'no' radio, then click the reset button, the callback function will log 'no' then 'yes'. I would have expected that it would be 'yes' and 'yes'!

const form = document.querySelector('form');

form.addEventListener('reset', () => {
  let getVal = () => form.querySelector('input:checked').value;

  console.log(getVal());
  setTimeout(() => console.log(getVal()), 0);
});

<form>
  <div>
    <label>
      <input type="radio" name="test" value="yes" checked>Yes
    </label>
    <label>
      <input type="radio" name="test" value="no">No
    </label>
  </div>

  <button type="reset">Reset Form</button>
</form>

Is it intentional that the callback for a form reset fires before the form has actually been reset? If so, why is this? Are there any advantages of this? It would seem much more logical to me that the reset event would fire immediately after the values are reset, to allow the callback to work with them..