language direction applied to list item removed after indentation

[Satya Minnekanti]

paste the following code in to source view.

 <ul>
	<li>
		List item 1 (LTR)</li>
	<li dir="rtl">
		List item 2 (RTL)</li>
	<li>
		List item 3 (LTR)</li>
</ul>

Go back to rich text, keep the cursor in 2nd list item and click on Increase Indent icon.

Expected Result A sub list is created with RTL Lang direction and language direction(dir="rtl") applied to 2nd list item remains.

Actual Result A sub list is created with RTL Lang direction but language direction(dir="rtl") applied to 2nd list item is removed.

[Jakub Ś]

The produced result is:

<ul>
	<li>
		List item 1 (LTR)
		<ul dir="rtl">
			<li>
				List item 2 (RTL)</li>
		</ul>
	</li>
	<li>
		List item 3 (LTR)</li>
</ul>

As You have noticed the RTL is applied to the main list element (ul). Why do you want to apply RTL direction to its children if they inherit this setting. In my opinion this would be extra and unnecessary attribute.

Is there some particular TC that makes my point of view wrong?

[Satya Minnekanti]

Replying to j.swiderski:

The produced result is:

<ul>
	<li>
		List item 1 (LTR)
		<ul dir="rtl">
			<li>
				List item 2 (RTL)</li>
		</ul>
	</li>
	<li>
		List item 3 (LTR)</li>
</ul>

As You have noticed the RTL is applied to the main list element (ul). Why do you want to apply RTL direction to its children if they inherit this setting. In my opinion this would be extra and unnecessary attribute.

Is there some particular TC that makes my point of view wrong?

@j.swiderski until yesterday the language direction(dir="rtl") applied to list item remains i'm seeing this new behavior only after i merged the latest changes from last night. So i thought this has happened bcoz of a regression from another fix.

[Jakub Ś]

@garry.yao has described and changed it in #8042.

For me it's appropriate behavior. Do you agree and we can close this issue or perhaps there is some special case which makes #8042 invalid?

[Satya Minnekanti]

Replying to j.swiderski:

@garry.yao has described and changed it in #8042.

For me it's appropriate behavior. Do you agree and we can close this issue or perhaps there is some special case which makes #8042 invalid?

@j.swiderski i agree, please close this defect.