[EuiSearchBar] Clear button hides RTL text

[nyurik]

When <EuiSearchBar> is in a RTL direction, the text is hidden behind the clear button. Also, both search and clear icons stay in the same location as for LTR, but should be reversed.

Example -- open sandbox and start typing in the search bar -- observe that the clear button appeared on top of the text.

[chandlerprall]

We'll likely need to address RTL concerns at a higher level than this case. Even if we want to support/fix RTL issues case-by-case (i.e. when they are reported), we need an official way to know when to apply relevant changes. A quick search did not find a way to programatically detect the applied direction for a given element - we'd likely need to walk the parent tree up until a dir and/or lang is found, allow specifying the direction on EuiContext, or using the context's existing locale config to inform the direction.

Another RTL-support question is if those languages should affect other presentation order such as table/grid columns.

[nyurik]

@chandlerprall thanks, yes, deciding the overall strategy would be needed. As for computing -- you don't need to walk the tree -- window.getComputedStyle(element).direction will give you the direction of any element.

Lastly, the order of the columns is already automatically reversed as soon as you set the dir=rtl, so this is not an issue. I believe this is how an rtl reader would expect it, but I'm no expert here - I can ask someone who has worked for many years in RTL and I18N to comment here.

[chandlerprall]

window.getComputedStyle(element).direction could work, thanks! Didn't realize it propagated through a CSS value like that.

For columns, there are places - like datagrid - where we programmatically handle the column display order.

[nyurik]

I just tried adding lang='he' dir='rtl' to the top div of the data grid example, and it seems it works ok. Is there something specific you are thinking about that would change?

P.S. I think the text would look correct if it was written in an RTL language. The actual strings are in LTR, and that's why I think we are viewing the trailing part.

Right-To-Left

Original

[chandlerprall]

Didn't expect you to go test it right away 😅 (but thank you, it's good validation!) - the virtualization work for rendering data grid is going to more explicitly set the column order. Currently, your RTL direction is modifying how the browser interprets flexbox ordering. Virtualization techniques rely on the app generating absolute positioning coordinates, which won't natively be aware of the direction. It's possible the virtualization librar(y|ies) apply this understanding, however. We'll find out soon enough!

[nyurik]

I just discovered a very well documented plugin that does CSS post-processing -- essentially converting logical back into physical properties but with proper fallbacks, etc.: postcss-logical

Example:

.banner {
  color: #222222;
  inset: logical 0 5px 10px;
  padding-inline: 20px 40px;
  resize: block;
  transition: color 200ms;
}

/* becomes */

.banner:dir(ltr) {
  padding-left: 20px; padding-right: 40px;
}

.banner:dir(rtl) {
  padding-right: 20px; padding-left: 40px;
}

.banner {
  resize: vertical;
  transition: color 200ms;
}

[cchaos]

As mentioned in Slack, the plugin sounds interesting but it would be better if we could find one that does the opposite so that consumers can decide if they need to support RTL languages. The main reason being that this will likely double our already bloated compiled CSS in the dist. Increasing the load for most consumers, since most won't be translating. Even Elastic products, at the moment, do not support RTL display.

It would also cause a huge update that means vigorous testing of all downstream effects that the EUI team doesn't have capacity to support at the moment including any subsequent windfall from consumer usage.

Dear @nyurik, you've definitely enlightened us on this topic and even introduced us to these "new" properties. Had we known 2 years ago, we most likely would have built around this concept. But retro-fitting now with all of EUI's usages is scary.

My ideal scenario:

1. Have an MD file in our Wiki that points to a webpack plugin that will help consumers compile our CSS for use with RTL languages. This would mean consumers would have to compile our library manually, but they can do this at build time and manage the output.
2. If/when Elastic decides to start translating to RTL languages, we'll have to tackle this conversion manually so we can test properly. This would likely be similar to our Typescript and soon-to-start CSS in JS conversions where we come up with a plan and execute over a long period of time. Probably ~6 months.

We can certainly update single components here are there as you come across ones that egregiously break in RTL languages. Individual components are easier than trying to do a blanket update.

[cee-chen]

As part of our Emotion conversion (#5685), we now have several logical property helpers (https://github.com/elastic/eui/blob/main/src/global_styling/functions/logicals.ts) that will automatically fix this issue once our form components are converted to Emotion.

I'm closing this issue for now as it's not a bug, it's a feature/functionality request that we currently do not support but will support OOTB as part of our Emotion migration.