BIDI - Support base text direction #7264
Comments
|
One could find more information about text direction on https://www.w3.org/International/articles/inline-bidi-markup/ |
joshblack
added
component: combobox
package: components
|
Just one precision. |
|
|
@joshblack I just noticed there is missing description of expected rendering of Hebrew text
Can be easily recreated in Notepad :
|
|
Example 2 tries show the problem with English text. Expected text would be please select an item .... and not ....please select and item Also: Item1 !!! and not !!! Item 1 |
|
Hey @adir01! 👋
Could you share more about what you're looking for support on? I believe text direction can be set on the product side, for things like layout bugs definitely happy to address them 👍 I think having a list handy for components that have the directional bugs would be a first step to planning how many items need to be addressed and how long. Hope this makes sense! |
|
Please find my answers:
Here is a list of components in which we would like to see correct text direction processing: Accordeon
a) review his changes in a short time period |
|
@adir01 thanks so much for putting the list together! From the discussion that you noted in #7683, it seems like the important thing for our team to remember is that there are two requirements:
And that these two requirements can individually be enabled or both enabled together. Is this correct? For the list of components, it will help out a ton to have steps to reproduce (ideally through our Codesandbox template) both to verify the issue and have a test case to make sure the issue has been addressed. I totally understand if this is a general problem, though, and just having a template that demonstrates it with a handful would be more than sufficient 👍 One note: some of the components in that list seem to potentially be named differently or might not exist in the system. Some of the ones I noticed:
|
|
Hello @joshblack , I am sorry for the late answer
This is correct.
Yes
I would remove this component for now because it unlikely contains user originated data.
You can safely remove this one.
We can also remove it for now because it actually contains other UI components inside. It would be better to enforce text direction on the sub components.
This is right
This is a mistake.
This is a mistake.
Right.
We can also remove it for now because it actually contains other UI components inside. It would be better to enforce text direction on the sub components.
OK |
|
Thanks for following up @wajnberg! Is one possible resolution here supporting In general, I think we'd be hesitant to add specific props per component for this kind of capability. It'd be great to come up with something general purpose that also handles the use-cases that are being brought up. |
Of course
|
|
I would say dir=auto could be used in principal if textDir can not be used , but in general case it is not good solution. dir=auto decides about text direction based on the first strong character, which is definitely not good decision in many cases. |
|
In general, I think we'd prefer to avoid adding a To try and illustrate why, we could start with a component with several text nodes being rendered by that component. function TestComponent() {
return (
<>
<span>Text node A</span>
<span>Text node B</span>
<span>Text node C</span>
</>
);
}In a situation where function TestComponent({ textDir }) {
return (
<>
<span dir={textDir}>Text node A</span>
<span dir={textDir}>Text node B</span>
<span dir={textDir}>Text node C</span>
</>
);
}Thankfully this situation is not bad at all, we could implement this as-is, add some tests, and call it a day. As components start to grow, or more text nodes are added, you could imagine that having to make sure these keep in sync can be tedious in terms of updating component code, tests, or making sure that all components pass around function TestComponent({ textDir }) {
return (
<>
<span dir={textDir}>Text node A</span>
<span dir={textDir}>Text node B</span>
<span dir={textDir}>Text node C</span>
<AnotherTestComponent textDir={textDir} />
</>
);
}Over time, we would need to manage This process prompted the idea of a common This idea is based on Facebook's Would love to hear what you all think, just sharing my train of thought when it comes to the |
|
Hello @joshblack That could be a great idea 👍 . However please keep in mind that text direction should be enforced only for user originated data (artifact name ...). So all fixed strings coming along with the product should not enforce text direction. |
Could you share more information / examples about this requirement? I'm not quite sure what this means in the context of this thread and would appreciate any additional info you could offer for this topic 👀 For example, in the above message, there is If this is the case, would there be a case for potentially any component in the system having a text node that is user-generated content? I could also be totally misunderstanding this so please let me know if I'm off here 👍 |
|
@wajnberg I think you’re totally right that you couldn’t scope it to a group of items inside of Combobox. The hope with this solution was to provide a way in which one could accurately determine the text direction of a node without having to add props for targeting text, or groups of text, inside of a component. This approach of adding props to target specific text or groups of text inside of a component is unfortunately not something that I think we could offer as part of the library. Is there a situation with the combobox example that you mentioned where this strategy would produce incorrect behavior? Or an aspect about it that is not preferred? |
|
Hello @joshblack , Let's assume we have a combo with 2 options and one title as follows: const items = [
{
id: 'option-0',
text:
'שלום עולם Hello !!',
},
{
id: 'option-1',
text: ''שלום עולם Hello 2 !!',
},
}
export const Playground = () => (
<div style={{ width: 300 }}>
<ComboBox
items={items}
itemToString={(item) => (item ? item.text : '')}
titleText:'my Title !!`
/>
</div>
);We want to display the options in RTL direction i.e we want to get the following: |
|
@wajnberg it might help to separate this from something like combobox and find a minimal example that breaks in the situations that you're describing. As an example, I updated that demo with the approach mentioned above. It has a component that's Combobox-esque, using the title and options that you provided: <SampleComponent
title="My Title !!"
options={[
{
id: 'option-0',
text: 'שלום עולם Hello !!',
},
{
id: 'option-1',
text: 'שלום עולם Hello 2 !!',
},
]}
/>To render the following image:
Link: https://codesandbox.io/s/modest-dew-mg5b6?file=/src/App.js Is this matching what you're hoping the component would be able to tackle? If not, what limitations are they / what situations would cause the issues to occur? |
|
Hello @joshblack , It's working because you use the const items = [
{
id: 'option-0',
text:
'שלום עולם Hello !!',
},
{
id: 'option-1',
text: ''שלום עולם Hello 2 !!',
},
}
export const Playground = () => (
<div style={{ width: 300 }}>
<ComboBox
items={items}
itemToString={(item) => (item ? item.text : '')}
titleText:'הכותרת שלי!!`
/>
</div>
);More generally the solution you propose is to refactor the |
|
@wajnberg I updated that codesandbox with the title you mentioned: <SampleComponent
title="הכותרת שלי!!"
options={[
{
id: 'option-0',
text: 'שלום עולם Hello !!',
},
{
id: 'option-1',
text: 'שלום עולם Hello 2 !!',
},
]}
/>To get the following result:
Link: https://codesandbox.io/s/modest-dew-mg5b6?file=/src/App.js Per your note about existing usage of Combobox, it seems like we have two directions we could take:
Let me know if I'm missing a situation, it seemed like you are concerned about a potential rewrite. My intent here is to, ideally, support this use-case without any Component API changes to Combobox. When looking at the overall impact of each direction, it seemed like the latter would have fewer changes while still supporting the same use-cases. If there is a use-case that it doesn't support that you're looking for, it would help out a ton to have a specific example and I can try and see how we can accomodate it. |
|
Hello @joshblack , The title should appear |
|
Thanks @wajnberg! That helps a ton. To force the <TextDirection
getTextDirection={(text) => {
if (text === title) {
return 'ltr';
}
return 'auto';
}}>
<SampleComponent
title={title}
options={[
{
id: 'option-0',
text: 'שלום עולם Hello !!',
},
{
id: 'option-1',
text: 'שלום עולם Hello 2 !!',
},
]}
/>
</TextDirection>To get the following image:
LInk: https://codesandbox.io/s/modest-dew-mg5b6?file=/src/App.js |
|
Hello @joshblack , Yes it's working now. |
|
@wajnberg that's totally right 👍 The change on our end would be to update components, including This is an alternative approach to the other strategy mentioned above where props would need to be added per component for determining text direction of things like labels, options, etc. |
|
Hello @joshblack I think I got the point now. When do you think the the components update would start ? Thank you so much for your help |
|
@wajnberg great question, I am trying to get a consensus now with the team. This type of change ultimately has a broad impact across the codebase and could impact parts of the code that downstream frameworks like Angular/Svelte/Vue who use our HTML as a reference. For transparency, the team is also working on our v11 release so we are trying to balance work there with support and types of issues like this that may require broader changes. I went ahead and opened up a draft PR to better summarize and discuss the changes brought up here and apply them to components to view in the storybook: #9013 |
|
@joshblack I'm not sure if this necessarily belongs in this issue since I don't know if this qualifies as a text direction ( Here is what a Button looks like: If the page uses This is how you get the asymmetric appearance because you've got 63px on the right and 15px on the left. But if the page is rtl, those two values need to be flipped and we would get and the button would look like this: Basically any time you have any css values with a |
|
Hello @TazmanianDI Thank you for your comments. The issue you describe has nothing to do with text direction |
|
@TazmanianDI As @wajnberg said: the problem that you describe is related to mirroring and has nothing to do with text direction which is addressed by this issue. However (unfortunately) the name of attribute that controls direction of static components ( i.e. Button) is textDir which is quite confusing. ( @joshblack probably it would be better rename it to something else (i.e |
|
@joshblack my understanding is that the first submission that is expected to resolve this issue and provide BIDI support for text direction for Accordion, Button, Checkbox, Combobox and Contentswitcher according to design agreed upon above is #9493 which is currently waiting your review. Can you please provide ETA for this PR and for remaining components processing? |
tay1orjones
changed the title
tay1orjones
added
the
planning: umbrella
tay1orjones
changed the title
|
It's been a while since we've looked at this, but there are still some components that have not been updated to use
There may be more now since that list was created |
|
With the latest PR, #14679, the initial list identified here is now complete and supports bidi via using If there's additional components or further work that needs to happen in relation to this issue, please open a new issue and reference/link here. Thank you! |
Base text direction is an integral part of the overall Bidi support and enables correct editing and readability of dynamic data for BIDI languages ( Arabic, Hebrew, Urdu)
Carbon code allows to specify following settings for the text direction, using textDir property :
However most of Carbon components does not apply text direction processing expected to happen according to this property settings and as a result of that , actual text direction inherits the page direction (which is by default LTR and is RTL when RTL style is applied), independently on textDir property setting
Examples:
Steps:
Apply RTL style on Carbon
Set textDir property = rtl
Text inside editor still has LTR text direction
Steps:
Apply RTL style on Carbon
Set textDir property = auto
Text at combo has RTL text direction
@mattrosno , @joshblack FYI
The text was updated successfully, but these errors were encountered: