RTLの番号付きリストや箇条書きが壊れています

バグ
1

実例: ההנחיות בוויקי לגבי שמות - ישראל (Israel) - OpenStreetMap Community Forum

このセクションは番号付きであるべきですが、おそらくCSSの問題でそうなっていません。

This image shows a screenshot of a post from zstadler on the OpenStreetMap community forum, featuring a red circle around some Hebrew text, with the text partially visible through the circle. (Captioned by AI)
This image shows a screenshot of a post from zstadler on the OpenStreetMap community forum, featuring a red circle around some Hebrew text, with the text partially visible through the circle. (Captioned by AI)1080×2096 140 KB

デスクトップではレンダリングが少し異なりますが、それでも壊れています。

ここでも実演してみます。フォーラムの設定に依存するかどうかはわかりません。以下のリストは、英語とヘブライ語で同一です。

番号付き:

  1. One
  2. Two
    1. Two point one
    2. Two point two
    3. Two point three
  3. Three
    • Three bullet one
    • Three bullet two

箇条書き:

  • Bullet one
  • Bullet two
    1. Bullet two number one
    2. Bullet two number two
  • Bullet three
    • Bullet three bullet one
    • Bullet three bullet two

ממוספר:

  1. אחת
  2. שתיים
    1. שתיים נקודה אחת
    2. שתיים נקודה שתיים
    3. שתיים נקודה שלוש
  3. שלוש
    • שלוש פריט אחת
    • שלוש פריט שתיים

פריטים:

  • פריט אחת
  • פריט שתיים
    1. פריט שתיים מספר אחת
    2. פריט שתיים מספר שתיים
  • פריט שלוש
    • פריט שלוש פריט אחת
    • פריט שלוש פריט שתיים

プレビューによると、ここでも壊れています。（編集：下にスクリーンショットを追加しました）

A screenshot of the Hebrew lists above, as rendered on Firefox on Android at the time of writing. Only the text is visible, but numbers and bullet points are not visible, and sub-lists appear on the same level as the top level list.
A screenshot of the Hebrew lists above, as rendered on Firefox on Android at the time of writing. Only the text is visible, but numbers and bullet points are not visible, and sub-lists appear on the same level as the top level list.1080×1382 126 KB

「いいね！」 2
2

修正案：

「いいね！」 1
3

ありがとうございます。これが承認されることを願っています！OSMフォーラムにもこのパッチを適用するためのリクエストを開きました：Fix list CSS for RTL languages - This forum issues and requests - OpenStreetMap Community Forum

追伸：このスレッドのOP（元の投稿者）は私にとって自動的に英語に翻訳されたようで、モバイルUIで元の言語を見る方法が見つかりません。これはどういうことでしょうか？もちろん、このケースでは問題はもう表示されなくなっています。以前にそのスクリーンショットを撮っておいてよかった！

4

これは正しいかもしれませんが、Udi、そのルールはプレビューに関するものだと思います。これらの一部は、使用しているCSSリバーサーのバグである可能性さえあります。

@Osama、これについて何か考えはありますか？

このバグを最優先で修正できると確信しています。

5

完全なルール（92行目参照）は次のとおりです。

.cooked,
.d-editor-preview {
  ul,
  ol {
     ...
  }
}

そのため、プレビューだけでなく、.cooked にも適用されます。

これはリバーサーのバグかもしれませんが、今後は start および end プロパティが最善の解決策となります。

Udi

「いいね！」 1
6

もちろん、マージしました。どう動作するか教えてください。

7

素晴らしい！

OPのヘブライ語セクションのスクリーンショットが正しくレンダリングされるようになりました。
OPのヘブライ語セクションのスクリーンショットが正しくレンダリングされるようになりました。1080×1366 141 KB

「いいね！」 1
8

リバースが適用されるのはUIの言語がヘブライ語やアラビア語などに設定されている場合だけだと推測していますが、こちらのケースではそうではありません。RTLテキストは、UIの言語がLTR（左から右）に設定されていてもコンテンツ内に現れることがあります。

Udiが述べたように、スタイルシートでは -inline-start/end を -left/right の代わりに使用し、誤りやすいリバース処理を避ける方がしばしば好ましいです。これにより、埋め込みのRTL（投稿内容内）とレイアウトのRTL（選択したUI言語に基づく）の両方に対して正しく動作し、1つのスタイルシートだけで済みます。これに移行してrtlcssを廃止することを検討しても良いでしょう。しかし、もちろん、解決すべき実際の問題がなければ、そうしなくても構いません。

「いいね！」 1
9

そうですね、私も同意します。混在コンテンツ用のしっかりとしたCSSスタイルシートを用意すべきです。他に改善が必要な例を見つけたら、PRも大歓迎です：ハグ:

「いいね！」 1
11

@nat タグを追加するのは良いアイデアですね。ここにも追加すると良いかもしれません: Wrong -> arrow direction in RTL text contexts (なぜか編集できません)。後で関連情報をそのスレッドに投稿します（ただし、要約すると、それは必要以上に大きな作業であり、OPに書いたことはまだ正しいです）。

「いいね！」 1
12

このAIアーティファクトで、この種の学習を少し行っていました。
https://meta.discourse.org/discourse-ai/ai-bot/artifacts/248/2

RTLフレンドリーにするために、多くの変更やパターンが必要になるようです。

この画像は、パディング、マージン、セーフアイランド、位置、左、右、上、下などのCSSプロパティと、それぞれの説明を概説しています。（AIによるキャプション）
この画像は、パディング、マージン、セーフアイランド、位置、左、右、上、下などのCSSプロパティと、それぞれの説明を概説しています。（AIによるキャプション）1426×1231 110 KB

解き明かして人々に教えるのは興味深いですね。境界線の部分も非常に興味深いです。

「いいね！」 1
13

興味深いと思っていただけて嬉しいです！私もそう思います :slight_smile:

AFAIK、-top と -bottom は問題ないことを付け加えておきます。-block-start と -block-end がそれぞれにマッピングされないことは非常に稀で、それはトップからボトムへのレイアウトを使用している場合にのみ発生するはずです。私自身は、そのようなレイアウトの経験は全くありませんし、ウェブサイト全体をそのようなレイアウトに対応させるために再設計する必要があると思いますので、これらの単純なCSSの調整ではうまくいかないでしょう。しかし、私の考えが間違っている可能性も十分にありますので、鵜呑みにしないでください！

編集：https://stackoverflow.com/questions/510068/how-do-i-make-text-run-top-to-bottom-in-css#53576895

「いいね！」 1
14

私がここで考えている質問は:

  • 私たちのCSSを、rtlcssがもう実行されなくてもよい状態にできるのか？
  • それは価値があるのか？
  • 健康的な中間状態は存在するのか？
15

おかしいことに、このページは、別の一般的な問題である、間違った方向にスクロールする様子を示しています。

残念ながら、これを調べたことがないので、原因や回避方法についてはお伝えできません。

「いいね！」 1
16

可能かどうか - 確かに可能ですが、CSS と連携するために HTML にいくつかの調整が必要になる場合があります（後で例を挙げることができます）。

健全な中間状態 - -inline-start に一部のものを変更した場合、rtlcss はそれらを無視しますが、-left の変換は継続すると予想されます。これは、より多くのものを段階的に切り替えることができるため、rtlcss が何も変更しなくなるまで続きます。その時点で rtlcss は引退させることができます。

価値があるかどうか - 全くわかりません。これにより Discourse が RTL でより安定するかどうか、また長期的に保守が容易になるかどうかを検討してください。本当にわかりません。

ユーザー生成コンテンツに適用される CSS にとっては、間違いなく価値がある - おそらく必要 - です。これはどちらの方向にもなり得ます（通常は dir="auto" を使用します）。

また、すぐに例を思いつくことはできませんが、レイアウトの方向に関係なく、何かの left プロパティを明示的に設定したい場合があります。その場合、rtlcss は間違ったことをするでしょう。ただし、何らかの方法でその例外を作成していない限り。

「いいね！」 1
17

例はこちらです：Fix display of RTL tag and role values in element info table by jake-low · Pull Request #790 · OSMCha/osmcha-frontend · GitHub

<td>要素内の追加の<span>要素は、テーブルを目的のレイアウトでレンダリングするために必要です。RTLコンテキストでは、::before疑似要素は右側に配置されます。したがって、td自体がRTLの場合、キーと値を区切る「=」記号は、テーブル行の末尾（右側）に配置されることになります。

基本的に、親要素とは異なる方向を与えるために、追加の要素をネストする必要がある場合があります。しかし、これは見方によっては良いことかもしれません。

「いいね！」 2
18

core、プラグイン、テーマ全体のCSSを更新してrtlcssへの依存を取り除くために努力する価値はあまりないと思います。健全な中間段階としては、投稿やバイオなどのユーザー生成コンテンツを含む部分には方向性に依存しないCSSを使用し、それ以外ではrtlcssがその役割を果たすことができるでしょう。

「いいね！」 3
19

このトピックは14時間後に自動的にクローズされました。新しい返信は禁止されています。