Les caractères de certaines écritures s'inscrivent de droite à gauche. Dans certains documents, notamment ceux en arabe ou en hébreu, et ceux avec un contexte de langues mixtes, plusieurs sens de lecture peuvent apparaître dans le texte d'un bloc (visuel) particulier. On appelle ce phénomène bidirectionalité, ou "bidi" pour faire court.
Le standard Unicode ([UNICODE], chapitre 3.11), définit un algorithme complexe pour déterminer la directionalité d'un texte. Cet algorithme comporte une partie implicite, basée sur les propriétés des caractères, et des contrôles explicites, portant sur leurs incorporations et leurs contraintes. CSS2 s'appuie sur celui−ci pour atteindre un rendu bidirectionnel convenable. Les propriétés 'direction' et 'unicode−bidi' permettent aux auteurs de spécifier une adéquation des éléments et attributs d'un document avec cet algorithme.
Quand un document contient des caractères allant de droite à gauche, et si l'agent utilisateur peut afficher ces caractères (dans les glyphes appropriés, et non pas avec des substituts arbitraires comme des points d'interrogation, un code hexadécimal, un carré noir, etc.), l'agent utilisateur doit utiliser l'algorithme bidirectionnel. En apparence, cette obligation est univoque ; bien que les textes des documents en hébreu ou en arabe ne contiennent pas tous de parties bidirectionnelles, ceux−ci sont plus enclins à en contenir (par exemple des nombres, des extraits en d'autres langues) que ceux des documents écrits de gauche à droite ne contiendraient de
parties écrites de droite à gauche.
Comme le sens de lecture d'un texte dépend de la structure et de la sémantique du langage du document, ces propriétés ne devraient la plupart du temps être utilisées que par les auteurs de descriptions de type de document (DTDs) ou d'autres documents spéciaux. Quand une feuille de style par défaut utilise celles−ci, les auteurs et les utilisateurs ne devraient pas spécifier de règles pour les surclasser. Une exception typique : la suppression du comportement bidi d'un agent utilisateur, et sa transcription du yiddish (habituellement en caractères hébreux) en caractès latins pour répondre à une requête de l'utilisateur.
La spécification HTML 4.0 ([HTML40], chapitre 8.2) définit le comportement bidirectionnel des éléments HTML. Les agents utilisateurs conformes pour HTML peuvent ignorer les propriétés 'direction' et 'unicode−bidi' des feuilles de style des auteurs et des utilisateurs. Le mot "ignorer" signifie ici que, si une valeur des propriétés 'unicode−bidi' ou 'direction' entrait en conflit avec l'attribut HTML 4.0 "dir", c'est la valeur de ce dernier que les agents utilisateurs peuvent choisir d'honorer. Ceux−ci ne sont pas tenus de reconnaître les propriété 'direction' et 'unicode−bidi' pour être conformes à CSS2, à moins d'être capables de représenter du texte bidirectionnel (et aussi, sauf pour le cas de HTML 4.0 comme précisé au−dessus). Les règles de style pour obtenir le comportement bidi, tel que défini dans [HTML40], sont intégrées dans l'exemple de feuille de style. Voir aussi la spécification HTML 4.0 pour d'autres questions liées à la bidirectionalité.
'direction'
Valeur : ltr | rtl | inherit Initiale : ltr
S'applique à : tous les éléments, mais voir les explications au−dessus Héritée : oui
Pourcentage : sans objet Médias : visuel
Cette propriété spécifie le sens d'écriture principal des blocs et le sens des incorporations et contraintes (voir 'unicode−bidi') pour l'algorithme bidirectionnel Unicode. En outre, elle spécifie le sens de mise en forme des colonnes des tables, le sens du débordement horizontal et l'emplacement d'une dernière ligne incomplète quand la propriété 'text−align' a pour valeur 'justify'.
Les valeurs de cette propriété ont la signification suivante : ltr
Sens de gauche à droite [ndt. left−to−right] ; rtl
Sens de droite à gauche [ndt. right−to−left].
La propriété 'unicode−bidi' doit avoir les valeurs 'embed' ou 'override' pour que la propriété 'direction' puisse agir sur les éléments de type en−ligne.
Note : Quand la propriété 'direction' est spécifiée pour les éléments des colonnes d'une table, celle−ci n'est pas héritée par les cellules des colonnes, les colonnes n'apparaissant pas dans l'arborescence du document. Ainsi, on ne peut pas adresser facilement les règles d'héritage de l'attribut "dir", telles que décrites dans la spécification [HTML40], chapitre 11.3.2.1.
'unicode−bidi'
Valeur : normal | embed | bidi−override | inherit Initiale : normal
S'applique à : tous les éléments, mais voir les explications au−dessus Inherited: non
Pourcentage : N/A Médias : visuel
Les valeurs de cette propriété ont la signification suivante : normal
L'élément n'ouvre pas un niveau supplémentaire d'incorporation en fonction de l'algorithme
bidirectionnel. Pour les éléments de type en−ligne, un réordonnancement implicite s'effectue au−delà des limites de l'élément ;
embed
Quand il s'agit d'un élément de type en−ligne, cette valeur ouvre un niveau supplémentaire d'incorporation en fonction de l'algorithme bidirectionnel. La propriété 'direction' donne le sens du niveau d'incorporation.
Le réordonnancement s'effectue implicitement à l'intérieur de l'élément. Celui−ci correspond à l'insertion
des caractères LRE (U+202A pour 'direction: ltr') ou RLE (U+202B pour 'direction: rtl') au début de l'élément et du caractère PDF à la fin de celui−ci ;
bidi−override
Quand il s'agit d'un élément de type en−ligne, ou bloc, ne contenant à son tour que des éléments de type en−ligne, ceci crée une contrainte. Cela signifie que le réordonnancement à l'intérieur de l'élément s'effectue strictement dans l'ordre de la propriété 'direction', la partie implicite de l'algorithme étant ignorée. Le réordonnancement correspond à l'insertion des caractères LRO (U+202D pour 'direction: ltr') ou RLO (U+202E pour 'direction: rtl') au début de l'élément et du caractère PDF (U+202C) à la fin de celui−ci.
L'ordonnancement final des caractères de chaque élément de type bloc est le même que celui décrit ci−dessus, comme si les caractères de contrôle bidi avaient été ajoutés, le balisage retiré et la succession de caractères qui en résulte, transmise à une implémentation de l'algorithme bidirectionnel Unicode comme du texte brut qui produirait les mêmes retours à la ligne que du texte stylé. Dans ce processus, les entités non textuelles, comme les images, sont traitées comme des caractères neutres, à moins que leur propriété 'unicode−bidi' n'ait une valeur autre que 'normal', auquel cas ces entités seraient considérées comme ayant une importance pour le sens indiqué par la propriété 'direction'.
Noter que pour autoriser l'écoulement de boîtes en−ligne dans une direction uniforme (soit entièrement de gauche à droite, ou inversement), plusieurs autres de ces boîtes en−ligne (dont des boîtes en−ligne anonymes) pourraient devoir être créées, et certaines d'entre elles devoir être découpées et réordonnée avant leur écoulement.
Du fait d'une limitation de l'algorithme Unicode à 15 niveaux d'incorporation, l'utilisation d'une autre valeur que 'normal' avec la propriété 'unicode−bidi' ne devrait se faire que de façon appropriée. Plus particulièrement, la valeur 'inherit' devrait faire l'objet d'une extrême prudence. Cependant, pour ceux des éléments destinés habituellement à un rendu en bloc (visuel), on préfèrera la spécification 'unicode−bidi: embed', pour conserver leur cohésion, dans le cas où leur propriété 'display' prendrait la valeur 'inline' (voir l'exemple plus loin).
Voici l'exemple d'un document XML contenant du texte bidirectionnel, qui illustre un principe de construction important : les auteurs de DTD devraient prendre en compte les questions bidi tant dans les éléments et attributs du langage concerné que dans les feuilles de style qui accompagnent le document. Celles−ci devraient être construites en distinguant les règles bidi des autres règles. Les règles bidi ne devraient pas être surclassées par d'autres feuilles de style, de manière à préserver les comportements bidi du langage du document ou du DTD.
Exemple(s) :
Pour cet exemple, les lettres en minuscules représentent des caractères lus de façon inhérente de gauche à droite, et les lettres en majuscules, ceux de droite à gauche :
<HEBREU>
<PAR>HÉBREU1 HÉBREU2 anglais3 HÉBREU4 HÉBREU5</PAR>
<PAR>HÉBREU6 <EMPH>HÉBREU7</EMPH> HÉBREU8</PAR>
</HEBREU>
<ANGLAIS>
<PAR>anglais9 anglais10 anglais11 HÉBREU12 HÉBREU13</PAR>
<PAR>anglais14 anglais15 anglais16</PAR>
<PAR>anglais17 <HE−QUO>HÉBREU18 anglais19 HÉBREU20</HE−QUO></PAR>
</ANGLAIS>
S'agissant d'un document XML, c'est la feuille de style qui indique le sens d'écriture. Voici celle−ci :
/* Règles bidi */
HEBREW, HE−QUO {direction: rtl; unicode−bidi: embed}
ANGLAIS {direction: ltr; unicode−bidi: embed}
/* Règles de présentation */
HEBREW, ANGLAIS, PAR {display: block}
EMPH {font−weight: bold}
L'élément HEBREU forme un bloc avec un sens de lecture de droite à gauche, l'élément ANGLAIS un bloc avec un sens de lecture de gauche à droite. Les éléments PAR sont des blocs qui héritent du sens de lecture de leurs parents, Ainsi, les deux premiers sont lus en commençant en haut à droite, et les trois derniers en commençant en haut à gauche. Noter que les noms des éléments HEBREU et ANGLAIS ont été choisis exprès pour la démonstration ; en général, ceux−ci devraient l'être pour refléter la structure du document, sans référence à la langue employée.
L'élément EMPH, de type en−ligne, dont la propriété 'unicode−bidi' a la valeur 'normal' (la valeur par défaut), celui−ci n'a pas d'effet sur l'ordonnancement du texte. Par contre, l'élément HE−QUO crée une incorporation.
Quand la ligne a une grande longueur, la mise en forme de ce texte pourrait ressembler à ceci :
5UERBÉH 4UERBÉH anglais3 2UERBÉH 1UERBÉH 8UERBÉH 7UERBÉH 6UERBÉH anglais9 anglais10 anglais11 13UERBÉH 12UERBÉH
anglais14 anglais15 anglais16
anglais17 20UERBÉH anglais19 18UERBÉH
Noter que l'incorporation de HE−QUO amène HÉBREU18 à se trouver à droite de anglais19.
Si les lignes devaient être découpées, cela pourrait ressembler à :
2UERBÉH 1UERBÉH −ÉH 4UERBÉH anglais3 5UERB −ÉH 7UERBÉH 6UERBÉH 8UERB anglais9 anglais10 an−
glais11 12UERBÉH 13UERBÉH
anglais14 anglais15 anglais16
anglais17 18UERBÉH 20UERBÉH anglais19
HÉBREU18 devant être lu avant anglais 19, il se trouve dans la ligne au−dessus d'anglais19. Un simple découpage de la longue ligne de la mise en forme précédente n'aurait pas été correct. Noter aussi que la première syllabe de anglais19 aurait pu tenir sur la ligne d'avant, bien que, pour les mots lus de gauche à droite dans un contexte de lecture de droite à gauche, et vice versa, leurs césures soient généralement supprimées pour éviter l'affichage d'un tiret en plein milieu d'une ligne.