You should be able to access the form elements directly after the dialog is closed. The returnValue tells you which button was pressed.

The example is a bit weird though. Rather than accessing the form elements to get the data, it pushes it into the "value" property of the confirm button.

So if you select an animal, returnValue is that animal, but if you click cancel, returnValur is "cancel". Which feels very clunky if you were to scale this behavior to any kind of complex form. I suppose the intention here was to show that it can be a dynamic value.

  // "Favorite animal" input sets the value of the submit button
  selectEl.addEventListener('change', (e) => {
    confirmBtn.value = selectEl.value;
  });

I agree. I’ve been using the <dialog> element at work for a few years now (with the polyfill). At first I experimented with using the returnValue, but as time went on I completely abandoned it in favor of just saving the form values in memory on confirm, and working with that.

Basically I listen to the submit event of my <form method="dialog"> which I preventDefault, then I close the dialog with a value of "confirmed" and fire a custom "confirm" event with the form values as detail. As for dismissing the form (e.g. the top x-mark or a cancel button), I have a non-submit button which resets the form, closes the dialog with a value of the empty string. I also listen to the cancel event on the dialog (e.g. user presses the escape key) and run the same dismiss method.

I guess my returnValue is therefor the empty string on cancel and a static "confirmed" on confirm, but honestly I’ve never actually used it outside of my initial experimentation when I felt like I should.

Yeah, I agree. Looking at GitHub it's not very popular and hasn't developed an idiomatic style of use. Most of the uses I saw were homework assignments.