9 Answers
9

Do not insert hyphens, not even soft hyphens &shy; (which only appear if the browser forces a line break). This is because the user might hand-write it or read-dictate it to someone else with the hyphen. Which would be inaccurate and bad.

You could however use the <wbr> element to indicate an optional word break opportunity. This will tell the browser to insert a line break as necessary to flow onto a new line inside the container.

A caveat of <wbr> is that it's not fully supported in all browsers (but degrades gracefully — will be ignored).

Note also that applying CSS hyphenation to the whole block could result in some ugly hyphenation of other longish words (eg. "followed") — but that's moving more into opinion and into the broader realm of hyphens and text-justification.

Forgot to mention that copy and pasting the text will ignore the hyphens — so no issue there
–
BaumrJan 11 '13 at 18:04

@Baumr: how do you ensure that? (Apart from the fact that hyphenating it still produces a visual inaccuracy)
–
Marjan VenemaJan 11 '13 at 18:26

I believe it's part of the CSS3 spec (but I haven't checked) just like when you set a background image it doesn't get copied. This guy suggests that both JS/CSS hyphenation is handled by the browser. Your <wbr> idea is a good one!
–
BaumrJan 11 '13 at 18:31

Great and interesting idea! But this is best for URLs (like Twitter does it), and probably not so good for emails as "conta..." can be very ambiguous, while "www.conta..." is less so.
–
BaumrJan 11 '13 at 19:07

Very interesting question, but I wonder if theoretical considerations are getting in the way of what is obvious here.

For scanarios where you a) know an email to be too long or b) have to account for dynamically inserted, potentially, too long emails, you can work around the issue. I agree that the problem described in your question is a valid one for displaying an email address in a small column.

For links like you have them, it is perfectly acceptable to display a link with the text of email, or something acceptable to the specific context that indicates that pressing the link will open the operating system's email dialog. The real address could be provided as a tooltip (most trivial solution via a title attribute on your anchor tag). Hovering will display the mailto:the-real-long-email@at-some-company.com email in the status bar, and, if you implement it, also in the tooltip.

Really all of the suggestions in your question seem unacceptable as they introduce ambiguity at one level or another. The only one that "works" is, in my opinion, the first image:

And by that I don't mean that this is the only real option to implement, but it is the only real non-ambiguous option. The way the email grows beyond the box simply tells you that the layout does not fully appreciate the content that is potentially placed in the box and needs adjusting. If adjusting the layout is not an option, you need can make the link text arbitrary.

Thanks, an interesting response exploring the possibilities of using different anchor text. However, in this context (and to keep this question from being overly broad), the email address must be displayed for various reasons. I liked Erics solution using <wbr, what do you think?
–
BaumrJan 11 '13 at 19:04

@Baumr compare your target site's usage to wbr support tables and you see if it is a viable option. One thing to keep in mind, however, is that whenever heading into technical difficulties it is a good point to investigate, if those could not be solved more delicately on a conceptual level.
–
konturJan 11 '13 at 19:12

Do not use hyphens, since they are ambiguous. They introduce the question “is the dash part of the address or not”.

You mention that copy and pasting is not an issue, but dictation or writing it yourself, is. If something is broken down like that, the user might prefer to write it herself, instead of copying, since selecting the text sometimes is awkward, and makes you select extra (or not all) characters.

Even cropping the text, like suggested, is a better option. The last thing you want here is ambiguity.

For as many times I've seen people try copy/pasting part of a wrapped URL and saying it's broken I don't think there's any way to do this that won't result in some users screwing up. While ugly I think the overflow is the lesser evil.

If you have to break; doing so at the @ is probably the least risky; followed by breaking at the . before the tld.

Can you provide some more detail about why you believe this is the best solution? This would not work for mobile users, for example.
–
Charles WesleyFeb 11 '14 at 20:35

Mobile users would need a different UI in any case…e.g., tap-and-hold. For desktop users: my suggestion is an extension of the solution offered above (ellipses). We’ve hidden content, so we need to reveal it upon request. No elegant solutions were offered above on how to reveal the information. Hovering is an intention, which means we can respond appropriately with the info-reveal.
–
jbxFeb 11 '14 at 21:23