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.
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.