Listes ordonnées en rtl bug sur ie7 (au moins)

Hello world,

je développe actuellement une version en arabe d'un site (multilingue).

L'adresse : par ici

J'ai passé tout le site en utf-8 (j'avais codé en iso avant que l'idée de la version ar n'apparaisse )

Comme d'habitude dans ce genre de site le contenu est parfois mixte ie occidental et arabe pour ce qui me concerne.

Apres abus et re-abus de la balise <dir="rtl"> - mais comment faire autrement ?? - tout se passe pas si mal sur FF 3.0 et ie8.0.

Mais voila gros soucis avec les listes sur ie7 (plus précisément mode compatibilité de ie8).

Mais alignements sautent et la puce se met un peu où elle veut !!


Apres avoir trituré la css sans résultat je n'ait laissé comme code spécifique au rtl que :

 [dir="rtl"]{
  margin-right:20px;
}

Bref je suis un peu paumé. Si quelqu'un avait des solutions a proposer ou des pistes je suis preneur.

Merci
icreM - j'en peux plus du rtl



PS : objectif final la validation complète du site mais c'est pas gagné
PS2 : les pages ou sa merde specialement : par la (2eme onglet en partant de la droite dans le menu du haut)

PS3 - 299$ à Carrefour : se mettre sur l'onglet arabe à l'extreme droite de la barre des langues en haut (je fourni la boussole pour ceux qui sont perdus) - bah oui sinon ca merde pas
Modifié par gilles6975 (18 Nov 2010 - 17:40)

Je m'auto repond mais toujours sans solution.

Le probleme survient uniquement dans les listes au contenu mixte.

J'ai essayé la propriété bidi mais sans grand résultat.

Voila je poursuit mes reherches.

Mes listes sont construits de la maniere suivante :

<ul>
<li> texte en arabe <span dir="ltr"> texte en fr</span> texte arabe</li>
</ul>

edition : le vrai casse tete
un code comme celui la s'affiche correctement

<ul>
<li> texte en arabe <span dir="ltr"> texte en fr</span></li>
</ul>

C'est donc l'aller retour qui semble poser probleme ??

Un conflit dans les balises dir ? J'ai essayé BDO et echec a nouveau.
Modifié par gilles6975 (19 Nov 2010 - 10:52)

Une journée sans solutions.. j'ai pourtant essayé des milliards de truc

ca va finir en recommandé pour ie8 ou supérieur

une petite capture du soucis pour se motiver (on voit bien les puces qui font n'importe quoi)


Modifié par gilles6975 (19 Nov 2010 - 18:40)

Hello,

Je connais très mal le sujet, mais il me semble que quand tu utilises l'attribut dir sur un élément, le navigateur va appliquer des styles CSS par défaut spécifiques. Par exemple dans le html.css de base de Firefox, tu as:

[dir="rtl"] {
    direction: rtl;
    unicode-bidi: embed;
}
[dir="ltr"] {
    direction: ltr;
    unicode-bidi: embed;
}
bdo[dir] {
    unicode-bidi: bidi-override;
}

La spec pour ces propriétés CSS:
http://www.w3.org/TR/CSS2/visuren.html#direction
Microsoft annonce ces deux propriétés comme supportées depuis IE5.

Peut-être IE7 a-t-il besoin que tu déclares certaines de ces propriétés explicitement? Je ne garantis rien mais il y a peut-être une piste à creuser ici.

Merci pour les specs Florent.

ca m'a mis sur une piste, j'ai essayé de mettre dans une page en dur une partie du code de la partie défaillante (partie générée en bdd via php).

Et là plus de soucis !!!

Cela ressert un peu la source du problème.

Affichage défaillant que pour les listes ordonnées à contenu mixte générées depuis la bdd.


C'est deja une piste !!


edition :

Petite question : pour afficher la langue arabe le navigateur bascule dans un mode graphique (glyphe) - voir : ici au paragraphe 3 - de ce fait est ce que les balises ouvrantes et fermantes c'est a dire " < et >" doivent etre codées en html avant insertion en bdd ? par exemple : &#60; pour < ?? pour ne pas etre interprétées comme des images mais bien comme des balises de code ?
Modifié par gilles6975 (20 Nov 2010 - 11:26)

Je m'auto repond je pense avoir trouvé la source du probleme :

sous ie7 en dynamique (php/sql/bdd) la source est :

	<li>
		<span dir="ltr">PILARw</span>&#1575;&#1604;&#1591;&#1585;&#1575;&#1586; &#1575;&#1604;&#1571;&#1585;&#1590;&#1610;&#1548; &#1604;&#1581;&#1605;&#1575;&#1610;&#1577; &#1575;&#1604;&#1602;&#1608;&#1575;&#1593;&#1583;&#1548; &#1608;&#1610;&#1605;&#1603;&#1606; &#1575;&#1587;&#1578;&#1582;&#1583;&#1575;&#1605;&#1607; &#1573;&#1604;&#1609; &#1580;&#1575;&#1606;&#1576; &#1606;&#1592;&#1575;&#1605; <span dir="ltr">PIVOT</span>&#1548; &#1606;&#1592;&#1575;&#1605; &#1605;&#1582;&#1589;&#1589; &#1604;&#1604;&#1605;&#1585;&#1575;&#1602;&#1576;&#1577;</li>
	

Le meme contenu en dur sous ie7 a pour source :

lol je peux pas la mettre le forum d'alsa l'interprete et me mets les caracteres encodé !!
bref dans la source les caractere arabe non encodées apparraissent !

reste maintenant a trouver la solution pour corriger cela.. c'est la seule différence ca doit donc etre la source du probleme !!
Modifié par gilles6975 (20 Nov 2010 - 11:38)

- Soit tes données sont enregistrées sous la forme d'entités HTML dans la base de données (ce qui est à éviter en général, c'est pas très souple...).
- Soit tes données sont enregistrées sous la forme de caractères arabes dans la base de données, et c'est à l'affichage qu'une fonction va les convertir en entités HTML. En PHP ce serait la fonction htmlentities par exemple.

PS: le forum est encore en ISO-8859-1 (héritage du passé ), et a donc du mal avec les caractères arabes.

Bien vu, mon texte en arabe est bien enregistré en entité html dans la base (et seulement celui-la), je pense que cela se fait automatiquement car j'avais mis betement l'interclassement "latin1_swedish_ci" dans la définition de la table. Or je suppose que ca n'est pas compatible avec l'arabe.

Ce n'est pas mon script de mise a jour de la base qui encode (pas de htmlentities() ou autre).

Il faut donc faire le bon choix pour l'interclassement. Je vais chercher ; j'ai aucun idée de comment faire.

Au passage heureusement que j'ai sauvegardé toutes mes pages arabes en dur ca va m'eviter de tout ressaisir

edit :

j'hesite entre cp1256 mais lequel prendre et utf8-bin ??
Modifié par gilles6975 (20 Nov 2010 - 17:46)

gilles6975 a écrit :
je pense que cela se fait automatiquement car j'avais mis betement l'interclassement "latin1_swedish_ci" dans la définition de la table

Non, à ma connaissance MySQL ne s'amuse pas à convertir du texte en entités HTML. C'est sans doute ton application qui fait ça. Si tu utilises un éditeur «WYSIWYG» en JavaScript tel que TinyMCE ou CKEditor, ils ont tendance à convertir les caractères non-ASCII en entités HTML aussi, avec leurs paramètres par défaut.

Je ne connais pas le site et l'importance de l'existant. Mais si tu veux mélanger plusieurs scripts (arabe et anglais ou arabe et français et plus encore), l'UTF-8 est idéal. Aujourd'hui plus de la moitié du Web est en UTF-8, c'est comme qui dirait incontournable.

Donc dans l'absolu il faudrait:
- avoir des pages déclarées en UTF-8 (dans le code HTML et côté serveur);
- avoir une base de données où les tables et les colonnes sont marquées comme étant en UTF-8 (l'interclassement utf8_general_ci devrait être correct);
- avoir des données en base qui sont bien en UTF-8, et qui n'utilisent pas d'entités HTML;
- ne pas faire de conversion caractère vers entité HTML en JavaScript ou PHP (ou autre langage utilisé), et ne pas faire de conversion d'un encodage vers un autre du côté de la base de données (bien vérifier la connexion).
Bref il faut être en UTF-8 tout au long de la chaine.

Ceci dit, si le site n'est pas en UTF-8 ce n'est pas forcément la solution la plus raisonnable de migrer toutes les données vers ce codage.