2013-08-22 5 views

risposta

8

Non è necessario per avvolgere il testo tra parentesi quadre in un arco separata.

Piuttosto, per risolvere questo problema aggiungere un carattere di controllo RLM (‏) dopo la parentesi di chiusura. Il carattere RLM agisce come un altro carattere ebraico/arabo e quindi la parentesi (che è un carattere debole) cambia direzione e si sposta nella posizione corretta.

Come così:

<div>מחיר אחד(3)&rlm;</div> 

NB: Se si imposta l'attributo dir="rtl" sull'elemento - allora anche il carattere di controllo RLM non è necessaria.

Come così:

<div dir="rtl">מחיר אחד(3)</div> 

CODEPEN (jsFiddle giù da me)

Questa microsoft doc spiega il carattere di controllo RLM insieme ad altri caratteri di controllo simili.

+0

Ho trovato il mio esempio nell'articolo non molto appropriato ~ hai ragione nella seconda linea di codici, quando uso dir = 'rtl' e thansk al browser tutto va bene (mi ricordo quando ho impostato questa domanda che ha incasinato. ..è questa la mia illusione o chrome aggiornato ..?) – sleepholic

+1

comunque il mio problema è stato risolto.Ma penso a una nuova condizione che quando uso una frase ebraica in inglese (ltr) o una frase inglese in ebraico (rtl) con parentesi, sarà anche scombina up.In il caso se noi non vogliamo sprecare un arco per avvolgere e lo stile della specifica frase lingua possiamo usare '‏' o '' ‎. – sleepholic

5

(aggiornato: grazie Rob per chiarire il tuo commento)

questo è un po 'di soluzione meno invasiva (result in jsFiddle):

<span lang="he" dir="rtl">מחיר אחד<span>(3)</span></span> 

Sembra ultimi parentesi è concidered come la punteggiatura e quindi trattati in modo diverso. This article mi ha dato un po 'di chiarezza:

... Si noti che a differenza align = "right", la punteggiatura sarà anche trasferito ... Vedere Sample RTL Document

Nel documento di esempio la stessa delocalizzazione degli ultimi parentesi si verifica anche all'interno del sottotitolo "Bidirectional Override (BDO)".

* verificata la soluzione jsfiddle in ultima cromo/ff/safari/ie

+0

siete a conoscenza se la soluzione si fornisce è un bug noto che si sta lavorando in giro o la soluzione è il modo corretto di affrontare il comportamento del browser previsto? In che browser hai testato la tua soluzione? – rob

+1

Dato che non ho familiarità con i linguaggi di rlt e quindi con le specifiche del browser, non posso essere sicuro al 100% se la mia soluzione è il modo corretto per affrontare la situazione data ma se le parentesi sono considerate come punteggiatura e come tali per il riposizionamento, un wrapper span sembra annullare quel comportamento. –

0

una delle soluzioni è quello di aggiungere **&#x200e;** dopo la parentesi

grazie alla @freeworlder per la soluzione su staffe visualizza erroneamente per diritto di stile di visualizzazione sinistra

addirittura è possibile utilizzare altri char, segui questo link http://www.codetable.net/hex/200e

Problemi correlati