Le rendu est un peu différent sur ordinateur, mais toujours cassé.
J’essaierai de le démontrer ici aussi. Je ne sais pas si cela dépend des paramètres du forum. Les listes suivantes sont identiques en anglais et en hébreu.
P.S. Il semble que le message initial de ce fil de discussion ait été automatiquement traduit en anglais pour moi et je ne trouve aucun moyen de voir l’original dans l’interface mobile. Que se passe-t-il ? Évidemment, le problème n’est plus visible dans ce cas. Heureusement que j’ai capturé cette capture d’écran plus tôt !
Ceci est peut-être correct Udi, mais je pense que cette règle ne concerne que l’aperçu. Certains de ces éléments pourraient même être un bug dans le CSS revereser que nous utilisons.
Je suppose que le générateur de reverser n’est appliqué que lorsque la langue de l’interface utilisateur est définie sur hébreu/arabe/etc., ce qui n’est pas le cas ici. Le texte RTL peut apparaître dans le contenu même lorsque la langue de l’interface utilisateur est de gauche à droite.
Comme Udi l’a mentionné, il est souvent préférable d’utiliser -inline-start/end plutôt que -left/right dans les feuilles de style, et de ne pas utiliser un reverser sujet à erreur. Cela fonctionnerait correctement à la fois pour le RTL intégré (dans le contenu des publications) ainsi que pour le RTL de mise en page (en fonction de la langue de l’interface sélectionnée), avec une seule feuille de style. Vous devriez envisager de migrer vers cette approche et de supprimer rtlcss. Mais bien sûr, ce n’est pas obligatoire si aucun problème réel à résoudre n’existe.
Oui, je suis d’accord, nous devrions absolument avoir une feuille de style CSS solide pour le contenu mixte, si vous trouvez d’autres exemples qui nécessitent des améliorations, une PR est totalement la bienvenue
@nat bonne idée d’ajouter la balise. Vous pourriez vouloir l’ajouter ici aussi : Wrong -> arrow direction in RTL text contexts (je ne peux pas l’éditer pour une raison quelconque). Je posterai des informations pertinentes dans ce fil de discussion dans une seconde (mais en bref, c’est toujours une tâche beaucoup plus importante qu’elle ne devrait l’être, et ce que j’ai écrit dans le premier message est toujours correct).
Je mentionnerai que, à ma connaissance, -top et -bottom conviennent. Il est extrêmement rare que -block-start et -block-end ne soient pas mappés respectivement à ceux-ci, cela ne devrait se produire que lors de l’utilisation de la disposition de haut en bas. Je n’ai personnellement aucune expérience de telles dispositions, et je pense que l’ensemble du site Web devrait probablement être repensé pour les accueillir, de sorte que ces simples ajustements CSS ne suffiraient pas. Mais, à tout prendre, je pourrais avoir tort, ne vous fiez pas à ma parole !
Est-il possible - absolument, mais cela pourrait nécessiter quelques ajustements en HTML pour coopérer avec le CSS (je pourrai donner des exemples plus tard).
État intermédiaire sain - Je m’attendrais à ce que si vous ne changez que certaines choses en -inline-start, rtlcss les ignore, mais continue de convertir -left. Cela signifie que vous pouvez progressivement passer de plus en plus de choses jusqu’à ce que rtlcss ne change plus rien. À ce stade, rtlcss peut être retiré.
Est-ce que ça en vaut la peine - aucune idée. Considérez si cela rendrait Discourse plus stable en RTL, et si ce serait plus facile à maintenir à long terme. Je ne sais vraiment pas.
Cela en vaut vraiment la peine - peut-être même nécessaire - pour le CSS appliqué au contenu généré par l’utilisateur qui peut aller dans les deux sens (généralement avec dir="auto").
De plus, bien que je ne puisse pas trouver d’exemple tout de suite, parfois vous voulez vraiment définir explicitement la propriété left de quelque chose, quelle que soit la direction de la mise en page. Dans ces cas, rtlcss ferait la mauvaise chose, à moins que vous n’ayez fait des exceptions pour cela d’une manière ou d’une autre.
Les éléments <span> supplémentaires à l’intérieur des éléments <td> sont nécessaires pour que le tableau s’affiche dans la mise en page souhaitée. Dans un contexte RTL, le pseudo-élément ::before se trouve à droite, donc si le td lui-même était RTL, le signe = séparant la clé et la valeur se retrouverait à la toute fin (côté droit) de la ligne du tableau.
En gros, parfois, il faut imbriquer un élément supplémentaire pour lui donner une direction distincte de son parent. Mais cela peut être une bonne chose selon votre point de vue.
Je ne pense pas que cela vaille la peine de faire tous les efforts nécessaires pour mettre à jour notre CSS dans le cœur, les plugins et les thèmes juste pour supprimer notre dépendance à rtlcss. Une étape intermédiaire saine pourrait consister à utiliser du CSS agnostique à la direction pour les zones contenant du contenu généré par l’utilisateur, telles que les publications et les biographies, et pour tout le reste, rtlcss fera l’affaire.
