On the markup: don’t nest buttons and links, they don’t play well together—the combination messes up various tooling, including screen readers (or so I’m told), and definitely messes up keyboard navigation with Tab and expected interactivity. Use one or the other. A link, most likely, so people can easily copy it:<p><pre><code> <a href="mailto:hello@tdarb.org?subject=RE:%20My%20Cheapskate%20Commenting%20System">Comment via email</a>
</code></pre>
You might hope that you could make it a full form, with a body field and all:<p><pre><code> <form action="mailto:hello@tdarb.org" target="_blank">
<input type="hidden" name="subject" value="RE: My Cheapskate Commenting System">
<textarea name="body"></textarea>
<input type="submit" value="Comment via email">
</form>
</code></pre>
… but in practice, application/x-www-form-urlencoded turns spaces into +, but + is ambiguous in mailto: URIs <<a href="https://datatracker.ietf.org/doc/html/rfc6068#section-5" rel="nofollow">https://datatracker.ietf.org/doc/html/rfc6068#section-5</a>> and generally interpreted as + rather than space. I don’t believe there’s any way to instruct browsers to emit %20 instead. As <a href="https://url.spec.whatwg.org/#concept-urlencoded" rel="nofollow">https://url.spec.whatwg.org/#concept-urlencoded</a> says, “the application/x-www-form-urlencoded format is in many ways an aberrant monstrosity”. I love it when language like that gets into specs, even if it’s only in non-normative notes. (The body field is probably not universally supported either, but with spaces being turned into plus signs, the absence of the body don’t signify so much.)<p>(If inspecting RFC 6068 carefully, you’ll note that line breaks also have to be encoded %0D%0A (␍␊); that one isn’t a problem, as HTML form data serialisation normalises that way already <<a href="https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#converting-an-entry-list-to-a-list-of-name-value-pairs" rel="nofollow">https://html.spec.whatwg.org/multipage/form-control-infrastr...</a>>—which I’ve seen trip up more than one char-count-limit implementation, with the server seeing two-char line breaks and the client seeing one-.)