P.S. it seems the OP of this thread was automatically translated to English for me and I can’t find a way to see the original in the mobile UI. What’s going on there? Obviously the issue is no longer visible in this case. Good thing I caught that screenshot earlier!
I’m guessing the reverser only gets applied when the UI language is set to Hebrew/Arabic/etc., this is not the case here. RTL text can appear in content even when the UI language is LTR.
As Udi mentioned, it’s often preferable to use -inline-start/end instead of -left/right in style sheets, and not using an error-prone reverser. This would work correctly both for embedded RTL (in post contents) as well as layout RTL (based on selected UI language), with only a single style sheet. You might want to consider migrating to that and retiring rtlcss. But of course, you don’t have to, if there isn’t a real issue to solve.
Yeah I agree, we should totally have a solid CSS stylesheet for mixed content, if you come across any other examples that need improving then a PR is totally welcome
@nat good idea adding the tag. Might want to add it here as well: Wrong -> arrow direction in RTL text contexts (I can’t edit it for some reason). I’ll post some relevant info in that thread in a second (but in short, it’s still a much bigger undertaking than it needs to be, and what I wrote in the OP is still correct).
I’ll mention that AFAIK -top and -bottom are fine. It’s extremely rare for -block-start and -block-end to not be mapped to them respectively, that should only happen when using Top-To-Bottom layout. I personally have no experience with such layouts at all, and I think the entire website would probably need to be redesigned to accommodate such layouts, so these simple CSS tweaks wouldn’t cut it. But by all means I might be wrong, don’t take my word for it!
Is it possible - definitely, but it might require a few tweaks in HTML to cooperate with CSS (I can give examples later).
Healthy intermediate state - I would expect that if you change only some things to -inline-start, then rtlcss would ignore them, but keep converting -left. This means you can progressively switch more and more things until rtlcss no longer changes anything. At that point rtlcss can be retired.
Is it worth it - no idea. Consider whether this would make Discourse more stable in RTL, and whether it would be easier to maintain long-term. I really don’t know.
It’s definitely worth it - perhaps required - for CSS applied to user-generated content that can go either way (usually with dir="auto").
Also, while I can’t think of an example off the top of my head, sometimes you really do want to explicitly set the left property of something regardless of the layout direction. In those cases rtlcss would do the wrong thing, unless you’ve made exceptions for that somehow.
The additional <span> elements inside the <td> elements are necessary to make the table render in the desired layout. In an RTL context, the ::before pseudo-element comes at the right, so if the td itself were RTL then the = sign separating the key and value would instead come at the very end (right side) of the table row.
Basically sometimes you need to nest an extra element to give it a separate direction from its parent. But this might be a good thing depending on your perspective.
I don’t think it would be worth the effort to go all out and update our CSS across core, plugins, and themes just to remove our dependence on rtlcss. A healthy intermediate step could be to use direction-agnostic CSS for areas that contain user-generated content such as posts and bios and for everything else rtlcss will do the job.
