text-overflow: ellipsis fighting with direction: rtl

Question

I like displaying emails properly, meaning not [at]. To fight the bots I reverse the text in the html and then re-reverse it with css using direction: rtl. That worked fine for many many years, until an email dared to break lines.

You can see what happens on the screenshots; kinda hard to explain–

Thats the mess that happens

This is how it looks when there is enough space

The http-host is always the same, so I figured using text-overflow: ellipsis together with white-space: nowrap and overflow: hidden on the <a>. That went south aswell;

(side note: it wasn't possible for me to fully highlight the visible text?) (The end of the highlight is NOT the end of the box!)

Okay; the text-overflow clipping comes first, then the reversing; I get it. So lets put overflow: hidden and text-overflow: ellipsis on the parent, which is a <p> and the white-space: nowrap on the a (scared that a telephone number will get chopped off)

I played around with a combination which styles go to the p and which to the a .. and I had one solution (which I unfortunately can't reproduce oO) where the dots were at the right side (which is what I want) but the text still gets chopped of an the visual left of the outcome, meaning the name name of the email, which I do not want to clip!

Long question short.. How can I get the following result? S.Rossa@park-reside...

When my email markup looks like this:

<a href="/email.php?to=rossa" class="direction">
<?php echo strrev("S.Rossa@park-residenz-alfeld.de"); ?>
</a>

Out of many reasons I cannot go back from the direction: rtl thing on the emails.

Please keep that in mind when suggesting a way to

1. keep the email from breaking lines, no matter what

2. and a convenient way to clip it with ...

3. with css only

Thanks!

Answer 1

The browser is given a string. When you tell it to shrink it and replace what doesn't fit with an ellipsis, it will always cut from the end of the string. It doesn't know your string is reversed and it trusts you when you tell it: this string should be read from right to left (direction:rtl). The end is on the left side.

Therefore, with CSS alone, the closest (and most decent) thing you can get is cutting from left side and placing the ellipsis where the cut was made:

a.direction {
  direction: rtl;
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;
  
  /* proof of concept: */
  width: 25%;
  display: inline-block;
}

<a href="/email.php?to=rossa" class="direction">&#x202e;ed.dlefla-znediser-krap@assoR.S</a>

You have two options now. Either

1. give up on text-overflow: ellipsis and fake it using JavaScript (works, but it's ugly) or...
2. you could reverse the string before you render it and give up on direction: rtl (which is actually a trick, it's not correct and is the source of the problem). Of course, you need to make sure you only do this for browsers, not for bots. The easiest way would be to check navigator.userAgent:

if (!/bot|crawler|spider|crawling/i.test(navigator.userAgent)) {
  var directions = document.querySelectorAll('.direction');
  for (var i = 0; i < directions.length; i++ ) {
    directions[i].textContent = directions[i].textContent.split('').reverse().join('');
  }
}

a.direction {
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;
  
  max-width: 25%;
  display: inline-block;
}

<a href="/email.php?to=rossa" class="direction">ed.dlefla-znediser-krap@assoR.S</a>

However, navigator.userAgent is not to be trusted, as malicious bots will never declare themselves as bots. So you might want to use safer methods of excluding bots, such as a link (clickable only by bots) pointing to a php script that would set a session variable for them. If the variable is set, just add an invisible element to your page and in the above JavaScript, instead of checking navigator.userAgent, check for the added element.
If you want the emails correctly indexed by certain search engines, you should exclude them from this check.