RTL layout issues

[moloko]

Subject of the issue/enhancement/features

In RTL content, the DOM order of the components is changed in a way that doesn't seem right. This seems to be do with the fix for #1670

Your environment

• FW 4.0.1
  (Should be possible to replicate in any FW version since v2.2.0)

Steps to reproduce

Using the out-of-the-box content, either set _defaultDirection to "rtl" in config.json or use the language picker extension to add an RTL language. Launch the course and go to the presentation components topic

Expected behaviour

The order of the components should change to match the RTL layout i.e. the text component should be on the right and the graphic component on the left. Furthermore, in mobile layout the order should remain the same as for the LTR layout i.e. the text component should be shown before the graphic component .

Actual behaviour

Although the order of the component in the DOM has changed, the visual layout has not: the text component is still on the left and the graphic component is still on the right. In mobile layout the graphic component is shown above the text component.

Screenshots (if you can)

[amygroshek]

If this helps, as discussed in gitter, at present AdaptModel.getChildren() rearranges left/right positioning of 2 components in a block, checking a _sortComponents variable. AdaptView.addChildren() is the place where components are reordered if lang dir is rtl.

It would seem to me that what's desired is to visually change presentation for RTL but I'm not clear that that requires the DOM reordering so much as CSS... If the text comes first in the DOM it will come first in the DOM whether rtl or ltr, no? Because that's the intent of the content creator with respect to a11y, and keyboard nav will always proceed vertically down through the DOM? And then the "reordering" could be handled with CSS, via a float or flexbox order... Curious to hear what others think.

[oliverfoster]

^ Agree with @amygroshek

DOM order swapping (prepend) needs removing and LESS needs fixing.

[moloko]

@guywillis any thoughts about how best to go about fixing the LESS? Swapping the .component-left and .component-right classes certainly worked for me - but whether that's the 'right' way to go about it or not I'm not sure...

[guywillis]

On the face of it, this seems like a relatively straight forward fix. But after a bit of digging I'm finding issues with all the solutions.

The different scenarios tested:

1. Leave auto sort on
2. Turn off auto sort
3. Turn off auto sort and add CSS to swap components
4. Turn off auto sort and swap component layout in js
5. Turn off auto sort and use display flex instead of floats

So where does that leave us...

1. As described in the issue above, with auto sort left on the DOM is out of alignment with expected behaviour and causes problems with mobile view and screen readers.
2. Turning off auto sort will resolve the mobile view and screen reader DOM order but will not flip the content visually so if a component was set to _layout: left in the LTR version it would still be visually left in the RTL version.
3. Alongside turning the auto sort off, using the CSS snippet below will visually flip the content and resolve the DOM order issue but it will introduce a potentially confusing scenario where if you originally built the course in RTL and you set a component to have a layout: left it will appear on the right visually.
4. Similarly, if we turn off the auto sort and then use JS to flip the components we'd run into the issue whereby your component is set to _layout: left in the json but it visually appears right if you were to build the course RTL first.
5. Even converting the components to use flexbox in place of floats causes a mismatch between the layout field in the json and visual output if building in RTL originally due to the RTL body direction property.

Options 3, 4, and 5 all produce the same outcome. I would recommend option 3 as the simplest and cleanest way of fixing the visual output whilst also being the easiest to remove should a course author build in RTL.

---

.component-left {
  @media all and (min-width:(@device-width-medium + 1px)) {
    .dir-rtl & {
      float: right;

      .component-inner {
        margin-right: inherit;
        margin-left: 5%;
      }
    }
  }
}

.component-right {
  @media all and (min-width:(@device-width-medium + 1px)) {
    .dir-rtl & {
      float: left;

      .component-inner {
        margin-left: inherit;
        margin-right: 5%;
      }
    }
  }
}

[moloko]

Thanks for this, I agree that option 3 sounds like the best way to go

a potentially confusing scenario where if you originally built the course in RTL and you set a component to have a layout: left it will appear on the right visually.

TBH I suspect if you are building something in RTL by default you'd probably be quite used to looking for gotchas like this seeing as how the web is so LTR-oriented!

[amygroshek]

Pardon me, I'm driving and not sure if replying this way will work, but it seems to me that the difficulty in finding a solution stems from the fact that we've got two directional layout settings that can conflict. We have the lang-dir setting and the component layout setting. What happens if we treat the layout setting like an order setting/order of importance setting? I realize I'm maybe proposing something that creates problems for backwards compatibility, but this would be easy to handle with either css or js if layout setting indicated primacy / proprity/ order of appearance of components relative to lang-dir. That's actually my assumption about it as I use it... If we approached it that way then the lang-dir would always be the overall determinant, and then component left/right would be handled relative to lang-dir. The layout values as they are are directional, which could be confusing, but in that context a layout of left, when handled on a page with an rtl language, would be more like an index-based order setting of 0... we put it wherever the learner's understanding of "first" would go.

…

On Fri, May 17, 2019, 5:52 AM Matt Leathes ***@***.***> wrote: Thanks for this, I agree that option 3 sounds like the best way to go a potentially confusing scenario where if you originally built the course in RTL and you set a component to have a layout: left it will appear on the right visually. TBH I suspect if you are building something in RTL by default you'd probably be quite used to looking for gotchas like this seeing as how the web is so LTR-oriented! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2389?email_source=notifications&email_token=AAFWFRUPMVWMLWMKTKK726DPV2E6BA5CNFSM4HAEPTTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVUN5SI#issuecomment-493412041>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFWFRXVQDF3MU57JSTJJM3PV2E6BANCNFSM4HAEPTTA> .

[moloko]

@amygroshek I'm not quite sure whether what you're suggesting is similar to what @guywillis is suggesting or completely different, could you elaborate a bit?

I can't think of anyway we can do this without at some point referring to 'left' and 'right' in a way that's going to be confusing to someone at some point!

I think it's safe to say that:

• the majority of Adapt content will always be LTR ^[1]
• people who develop for RTL will be used to working in a world that's very LTR-centric.

Therefore we should go with the solution that is confusing to the fewest amount of people.

^[1] A brief bit of research suggests there are ~1 billion speakers of RTL languages in the world, i.e. 14% of world's population speak an RTL language.

[moloko]

should be fixed by 667adf7