Frankasdf: unicode-bidi mit seltsamem Verhalten

Hallo an alle CSS-Freaks,

auch nach Jahren finden sich noch völlig verblüffende Effekte.
Ich will eine E-Mail-Adresse vor Crawlern ein wenig verschleiern mit folgendem Code:
So soll es aussehen:
Mail: me@domain.de 48 Stunden vorher.
Hier der Code
Mail: <a href="mailto:me" onclick="location.href= this.href + '@domain.de';return false;" style="unicode-bidi: bidi-override;direction: rtl;">ed.niamod@em</a> 48 Stunden vorher.
und so wird es dargestellt:
Mail: 48 me@domain.de Stunden vorher. Die 48 wird also mit in den style einbezogen.

Wenn ich die 48 durch xx ersetze wird es korrekt dargestellt, also
Mail: me@domain.de xx Stunden vorher

Das heißt, alle meine Browser (IE,FF,Opera,Safari) entscheiden die Darstellung nach dem Inhalt. Das finde ich krass. Wo liegt hier mein Denkfehler?
Die Codepage spielt übrigens keine Rolle.

Viele Grüße und Danke schon mal im Voraus

Frank

  1. Da muss ein Grund sein, warum hier niemand so schnell helfen will:
    --Javascript für die Emailadresse voraussetzen,
    --CSS für die Emailadresse einsetzen,
    --Fragwürdie Methdode...

    Anyway:
    Versuche mal, dem übergeordneten Absatz ein ltr zu verpassen. damit gibst du eine Grundorientierung auch für an und für sich nicht richtungsdeterminierende Unicode Punkte.

    Wenn's funktioniert:
    Überdenke deinen Ansatz und mach eventuell etwas anderes.

    mfg Beat

    --
       <°)))o><                      ><o(((°>o
  2. Hi,

    Das heißt, alle meine Browser (IE,FF,Opera,Safari) entscheiden die Darstellung nach dem Inhalt. Das finde ich krass. Wo liegt hier mein Denkfehler?

    Du bist sehr tief in die Abgründe des Unicode-Bidi-Algorithmus gestoßen. ;-)

    CSS sagt nämlich (siehe http://www.w3.org/TR/CSS2/visuren.html#direction):

    | This corresponds to adding a LRO (U+202D; for 'direction: ltr') or RLO
    | (U+202E; for 'direction: rtl') at the start of the element and a PDF
    | (U+202C) at the end of the element.

    Betrachte nun folgenden HTML-Code:

    <p>Mail: &#x202e;tset.niamod@em&#x202c; 48 Stunden vorher.</p>

    Da ist kein CSS mehr, dafür die RLO und PDF-Steuerzeichen mit drin. Das ist äquivalent zu Deiner CSS-Geschichte - und siehe da: auch hier wandert das 48 vor Deine E-Mail.

    Warum ist das so? Es gibt einen relativ komplizierten Algorithmus, den Unicode-Bidi-Algorithmus, der dafür verantwortlich ist, siehe http://www.unicode.org/reports/tr9/.

    Was sagt der nun?

    1. Der Absatz selbst hat die Default-Richtung L, aber nicht forciert (d.h. sollte ein R-Zeichen auftauchen, wird die Richtung selbstständig geändert). Das RLO-Zeichen startet nun einen Override-Abschnitt, wo alle Zeichen forciert die Richtung R bekommen. Das PDF-Zeichen beendet nun den Override-Abschnitt und der normale Abschnitt geht weiter.

    D.h. Du hast folgende Situation:

    Text: Hallo &#x202e;tset&#202c; 48 Stunden.

    Einzelne Zeichen mit ursprünglichen Eigenschaften (_ == Leerzeichen, | == Spezielles Bidi-Zeichen):

    H   a   l   l   o   _   |   t   s   e   t   |   _   4   8   _   S   t   u   n   d   e   n
      L   L   L   L   L   N       L   L   L   L       N   EN  EN  N   L   L   L   L   L   L   L

    Nun wird nach Regel X4 die Eigenschaft zwischen den Trennzeichen explizit geändert:

    H   a   l   l   o   _   |   t   s   e   t   |   _   4   8   _   S   t   u   n   d   e   n
      L   L   L   L   L   N       R   R   R   R       N   EN  EN  N   L   L   L   L   L   L   L

    Nun werden nach Regel X9 die Unicode-Sonderzeichen entfernt:

    H   a   l   l   o   _   t   s   e   t   _   4   8   _   S   t   u   n   d   e   n
      L   L   L   L   L   N   R   R   R   R   N   EN  EN  N   L   L   L   L   L   L   L

    Nun wird nach Regel N1 das vorher neutrale Leerzeichen nach "tset" in zu einem Leerzeichen mit R-Eigenschaft:

    R  N  EN → R  R  EN  [Aus den Regeln]

    H   a   l   l   o   _   t   s   e   t   _   4   8   _   S   t   u   n   d   e   n
      L   L   L   L   L   N   R   R   R   R   R   EN  EN  N   L   L   L   L   L   L   L

    (Die anderen N werden auch noch aufgelöst, aber die sind relativ egal.)

    Das heißt jetzt aber folgendes: Du hast jetzt einen Text, der einen Abschnitt "Hallo" enthält, der LTR ist, einen Abschnitt "tset 48", der RTL ist (EN nach R ist fast wie R, EN nach L ist wie L) und Du hast einen Abschnitt "Stunden" der wieder LTR ist, d.h. Du hast 3 Abschnitte und der mittlere wird umgedreht.

    Weil also 48 Zahlen sind, wirkt sich das hier auch darauf aus. Die Browser machen es hier also alle vollkommen richtig, auch wenn das zu WTFs Deinerseits führt. ;-)

    Mögliche Auswege:

    1. Das einschließende Element mit »style="direction: ltr; unicode-bidi: bidi-override;"« angeben, dann wird Typ L auf die Zahlen forciert (das innere Element überschriebt dagegen das wieder), z.B.

    <p style="direction: ltr; unicode-bidi: bidi-override;">Mail: <a href="mailto:me" onclick="location.href= this.href + '@domain.test';return false;" style="unicode-bidi: bidi-override;direction: rtl;">tset.niamod@em</a> 48 Stunden vorher.</p>

    1. An den Anfang des vorigen Elements ein U+202D einfügen, damit LTR forciert wird:

    <p>&#x202d;Mail: <a href="mailto:me" onclick="location.href= this.href + '@domain.test';return false;" style="unicode-bidi: bidi-override;direction: rtl;">tset.niamod@em</a> 48 Stunden vorher.</p>

    1. U+202A oder U+202D vor das 48 (aber *nicht* direkt nach </a> sondern erst *nach* dem Leerzeichen):

    <p>Mail: <a href="mailto:me" onclick="location.href= this.href + '@domain.test';return false;" style="unicode-bidi: bidi-override;direction: rtl;">tset.niamod@em</a> &#x202d;48 Stunden vorher.</p>

    Viele Grüße,
    Christian

    1. Hi Christian,

      deine ausführliche Antwort verdient noch mal einen extra Dank. Das ist ja schon ziemlich hohes Niveau - und das Verblüffende: alle Browser machen es richtig ;-)

      Gute Nacht

      Frank