P.S. 이 스레드의 원저자(OP) 글이 제 모바일 UI에서 자동으로 영어로 번역되어 있는 것 같고, 원래 글을 볼 방법을 찾을 수 없습니다. 무슨 일이 일어나고 있는 건가요? 당연히 이 경우에는 문제가 더 이상 보이지 않습니다. 다행히도 전에 그 스크린샷을 찍어 두었네요!
리버서(reverser)는 UI 언어가 히브리어/아랍어 등으로 설정된 경우에만 적용되는 것 같고, 여기서는 해당 사항이 아닙니다. UI 언어가 LTR로 설정되어 있더라도 콘텐츠 안에 RTL 텍스트가 나타날 수 있습니다.
우디가 언급했듯이, 스타일시트에서는 오류가 발생하기 쉬운 리버서를 사용하지 않고 -inline-start/end를 -left/right 대신 사용하는 것이 종종 더 바람직합니다. 이렇게 하면 단일 스타일시트로 임베디드 RTL(게시물 콘텐츠 내)과 레이아웃 RTL(선택된 UI 언어 기반) 모두에서 올바르게 동작합니다. rtlcss를 폐기하고 해당 방식으로 마이그레이션하는 것을 고려해 볼 수 있습니다. 물론 해결해야 할 실질적인 문제가 없다면 그렇게 하지 않아도 됩니다.
@nat 태그를 추가하는 건 좋은 아이디어네요. 여기에도 추가하면 좋을 것 같습니다: Wrong -> arrow direction in RTL text contexts (어떤 이유인지 모르겠지만 제가 편집할 수 없습니다). 잠시 후 해당 스레드에 관련 정보를 몇 가지 올리겠습니다 (요약하자면, 여전히 필요한 것보다 훨씬 큰 작업이고, 제가 OP에서 쓴 내용은 여전히 정확합니다).
제가 아는 한, -top과 -bottom은 문제없습니다. -block-start와 -block-end가 각각 해당 값으로 매핑되지 않는 경우는 매우 드물며, 이는 Top-To-Bottom 레이아웃을 사용할 때만 발생할 수 있습니다. 저는 그런 레이아웃에 대한 경험이 전혀 없고, 그러한 레이아웃을 수용하려면 웹사이트 전체를 다시 디자인해야 할 것 같아서, 이런 단순한 CSS 조정만으로는 부족할 것 같습니다. 하지만 제 말이 틀렸을 수도 있으니, 제 말만 믿지 마세요!
가능성은 - 물론이지만, CSS와 협력하기 위해 HTML에 몇 가지 조정이 필요할 수 있습니다 (나중에 예를 들어볼 수 있습니다).
건강한 중간 상태 - 일부 항목만 -inline-start로 변경하면, rtlcss는 그것들을 무시하고 -left 변환은 계속할 것으로 예상합니다. 이는 rtlcss가 더 이상 아무것도 변경하지 않을 때까지 점점 더 많은 항목을 전환할 수 있음을 의미합니다. 그 시점에 rtlcss는 폐기할 수 있습니다.
그렇게 할 가치가 있는가 - 모르겠습니다. 이것이 Discourse의 RTL 안정성을 높일지, 그리고 장기적으로 유지보수가 더 쉬워질지 고려해 보십시오. 정말로 모릅니다.
확실히 가치가 있는 경우 - 양쪽으로 갈 수 있는 사용자 생성 콘텐츠(보통 dir="auto" 사용)에 적용되는 CSS에는 - 아마도 필수적일 것입니다.
또한, 머릿속에 떠오르는 예는 없지만, 레이아웃 방향과 관계없이 특정 항목의 left 속성을 명시적으로 설정하고 싶은 경우가 실제로 있습니다. 그러한 경우, 어떤 식으로든 예외를 만들지 않는 한 rtlcss는 잘못된 작업을 수행하게 됩니다.
<td> 요소 내부의 추가적인 <span> 요소는 테이블이 원하는 레이아웃으로 렌더링되도록 하는 데 필요합니다. RTL(오른쪽에서 왼쪽으로) 컨텍스트에서 ::before 의사 요소는 오른쪽에 위치하므로, td 자체도 RTL이라면 키와 값을 구분하는 = 기호가 테이블 행의 가장 끝(오른쪽)에 위치하게 됩니다.
기본적으로 부모 요소와 다른 방향을 지정하기 위해 추가 요소를 중첩해야 하는 경우가 있습니다. 하지만 관점에 따라 이는 좋은 일이 될 수도 있습니다.
핵심, 플러그인, 테마 전체의 CSS를 업데이트하여 rtlcss에 대한 의존성을 완전히 제거하는 데는 상당한 노력이 필요하므로 그만한 가치가 없다고 생각합니다. 건강한 중간 단계로는 게시물이나 자기소개서와 같이 사용자가 생성한 콘텐츠를 포함하는 영역에 방향성과 무관한 CSS를 사용하는 것이 좋겠습니다. 나머지 영역은 rtlcss가 역할을 수행할 것입니다.
