Should mailto be used in HTML5?
Asked Answered
L

5

17

A year or so ago I decided to stop using the mailto tag because many times it is annoying to the user. It will bring up an email program that the user may not be using at the time, which may also take time to load and may not be what the user wanted to do when he/she clicked on what looked like a link.

Instead I decided to just start displaying the email address without the mailto tag. I believe that both ways probably can produce spam.

My questions are these, Is the mailto tag the accepted way to setup email links, or do good people/companies avoid them? Second, if they both create spam, is there a way to prevent spam from being generated on either? I have seen the mailto being put inside comments somehow, but it seems kind of a hacked way of doing it.

Latex answered 10/11, 2010 at 3:37 Comment(1)
+1 for the clear explanation of reasons to stop using mailtoOlio
D
19

You should use the mailto: URI scheme in both HTML4 and HTML5.
If the user doesn't want a mail client to load, he won't click the link.
Not using mailto: just makes it more annoying to send you email.

Any half-decent (indecent?) spam crawler will pick up email addresses whether or not they're in mailto:.

One effective way to prevent this is to include a (trivially-)encrypted version of the email address in Javascript and write it into the document.
This way, any spam crawlers that do not execute Javascript won't get your address.
If you're afraid of spam crawlers that do use Javascript, you can only write the email address on mousemove and/or after 5 seconds.
For accesibility reasons, and for humans with Javascript disabled, you may want to include a scrambled form of the address in plain text. (eg, SLaks (SHIFT+2) MyDomain (period) com)
You can write a server-side script to generate this automatically for an email address.

For obvious reasons, I won't share code. (In order for this to work well, each site should have a different implementation)

Dun answered 10/11, 2010 at 3:38 Comment(4)
For those who are afraid of spam crawlers who use Javascript, another method is to write the email in an image (and then put that iamge in your website). Unfortunately, we cannot espace definitely from spam.Caty
@pablofiumara: You are substantially underestimating modern OCR. There is a reason why CAPTCHAs are so hard.Dun
If you're using email, spambots already have your email address. Trying to avoid spam by hiding your email address in modern times is like trying to avoid junk mail by painting over your house number. Invest your time in a better spam filter and don't make it hard for real people to contact you.Oloughlin
@Oloughlin Not necessarily. If you use a service like SpamGourmet (which I've been using since before 2010), then you can successfully keep spambots from knowing your e-mail address by handing out aliases and just retiring them when they leak. Heck, aside from my Kickstarter address leaking and needing to be changed, all the spam I remember receiving came from my being too lazy to toughen up the contact form on my websites. (A problem now remedied.)Saury
F
7

I usually see companies using a server-processed contact form instead of publishing email addresses. Most web geeks I know tend to use some sort of JavaScript obfuscation to write out their email addresses, which will admittedly leave non-JS browsers/users in the dust. A compromise would be to use images. (Yuck.)

To get to the heart of your question, I absolutely use mailto: all the time where appropriate. It is a meaningful way to convey to a browser what to do with a link. Users are free to configure what email client to open these links in using the relevant browser and/or OS options.

Fulton answered 10/11, 2010 at 3:39 Comment(0)
L
1

My perception is that the use of mailto is not related to HTML5 or any other markup spec, but a matter of personal/company coding convention. If you choose to deprecate the protocol, then that's fine, but it will not make any notable difference to spam.

It might be useful to do some A/B testing to replace the mailto with a contact form and see the difference in response rates...

Lucy answered 10/11, 2010 at 3:42 Comment(0)
M
0

I recommend only using the mailto protocol when the displayed text is an email address; otherwise, the user may not understand that he is clicking on a mailto link.

As far as spam, if you put an email address in your HTML, it's susceptible to spam. You could use JavaScript to dynamically insert email addresses into the DOM, but users without JavaScript won't be able to see the email address.

Makkah answered 10/11, 2010 at 3:41 Comment(0)
P
-1

As noted on https://seibert.group/blog/en/why-mailto-links-should-be-avoided-on-websites/ mailto links are a usability nightmare. I highly recommend reading that article (it's not that long, and I have no affiliation to it BTW), but below is a summary for Stack Overflow.

Usability problems

  • The user has a high chance of not having an e-mail client installed

    • eg. anyone who uses webmail probably has none
  • Disappointed user expectations

    • When people click a link, they expect to go to a webpage, not their email client
  • Long loading times

    • When you click a mailto link, you have to wait a long time for the client to load; it's the polar opposite of a quick web experience

There are also analytics and security concerns (see the article for them). Also, while it's not in the above list, you have to keep in mind that many (most?) mailto links will be on accident, because very few users in 2024 want to open their email client when they click a link.

My personal recommendation is to:

  • leave most email addresses unlinked
    • better for the user because they can't accidentally open their email client
  • if the user really needs to interact with that email address (eg. send an email) copy it to the copy/paste buffer (using Javascript) when they click the link
    • for the best user experience, display some sort of notification informing them that you copied it (eg. an alert, although most modern UI frameworks have a less disruptive equivalent)
Perhaps answered 16/7, 2024 at 16:53 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.