I think if my mom was trying to submit a form, and it opened her email client with a body consisting of URL encoded data she’d probably just close the email client thinking that something went wrong. Then she’d try again and the same thing would happen again. Then she might call me, and I’d probably tell her to just forget about it and try to call them on the phone instead or give up and try another company instead.
The e-mail client decodes the URL encoded data. So you actually see plain text. The encoding is only done for the purpose of passing the data from the browser to the e-mail client.
I created a form with a dropdown and a some other inputs.
The result when using enctype=application/x-www-form-urlencoded and method=post in the form html is that the body that is shown in my email client is URL encoded.
They have a different enc type that you could use to specifically make it plain text. That one is not recommended because then you're gonna have a bad time parsing out the fields that were submitted from the form.
One variant that seemed interesting was method=get with enctype=application/x-www-form-urlencoded
In this case the values from the form get added as headers in the email so they are not directly visible to the user
I thought that I could still add user-visible subject and body by adding ?subject=foo&body=bar to the mailto: url
For example I could then have the subject say "Web form submission", and have the body of the mail contain a description that tells the user to send the email and that the data they filled into the form will be sent along with the email.
Even that is not great UX imo, but could still be interesting.
However from my testing with Brave web browser and Apple Mail, the subject and body are not filled in for the user in this case.
You see that in the "email" forms of for example most "contact" sites.
Like, for example, here on HN, in the right end of the site's footer (on desktop), by clicking "Contact" (but this isn't a form, just a "mailto:..." link).
