Automatic RTL detection

[Tal500]

Following #89, I am wondering why can't the library detect automatically whether it's in RTL or not.
The discussion has started because of the following discussion in the Svelte port of this library.

The idea I said there is to detect automatically the direction by the expression getComputedStyle(container).direction === 'rtl', instead of the manual API property rtl (discussed there in more details).
I am a native Hebrew speaker, so I have an experience with those types of issues.

Sometimes it is even essential to detect this automatically, since the component using this library might be contained in a different component, which allow the end user switch dynamically the text direction (e.g. changing the language from English to Hebrew shall change the text direction from LTR to RTL), and the inner component might not be aware of this change, so it couldn't change the API property rtl.

If for some reason(that makes no sense for me) you'd like to give the user a control to override this automatic RTL detection, I'm suggesting then to convert the type of the API property rtl to boolean | undefined, with a default value of undefined (meaning automatic detection).

I would like to here your opinion 🙂

[antoniandre]

Hi @Tal500, late to the party again.

I hear you, but I’m not fully convinced that detecting RTL automatically from within the library is the right approach.

Splitpanes isn’t responsible for detecting RTL, just as it doesn’t handle browser theme preferences, OS themes, locales, breakpoints, and other similar settings that might later become relevant. While adding this detection is not complex, it sets a precedent for similar feature requests in the future, which could lead to unnecessary scope creep.

Moreover, automatic detection alone may not be reliable in all cases:
• The user changes the locale dynamically, and the content is no longer RTL.
• Splitpanes is initialized before the RTL direction is set, leading to incorrect behavior.
• If the container is not attached to the DOM when detection runs, getComputedStyle might not return the correct value.

That being said, I appreciate your experience with these issues and value your opinion. I’m open to further discussion if you think there’s a way to handle this robustly.

[Tal500]

Thanks for the response!
I shall explain briefly what RTL in browser means, and what behaviour change it requires here:

1. RTL isn't about theme, it's about the "language" of the specific HTML content, not an end user browser configuration, but rather a frontend content creator choice.
2. The detection for that is a very easy and fast JS CSS query.
3. The RTL affects the user experience in two ways:
   a. That the first pane is to the left, and the second pane is to the right (unlike LTR). here is the magic: for this support, it requires nothing from the library, as this is currently the case by the static HTML output.
   b. That when the user drag the separator, the pane "width" values is the distance starting from the right of the screen(instead from the right as of LTR), but the cursor "x" coordinate however, is still the cursor distance from the left(both in RTL and LTR). So the only code change that is needed is to invert the "x" cursor coordinate on the splitter dragging handler - to detect at that moment by a JS CSS query whether the mode is RTL, and if so, replace the cursor "x" coordinate by windowWidth - x - that's all! (see the straitforward implementation in the svelte port)