RTL/Bidi CSS guidelines for Gaia

[Sam Foster]

For 2.5, we are committed to finishing the work we started in 2.2 to fully support RTL in Gaia(1). A part of this project is to do some minor refactoring of our existing CSS to provide a better foundation for ongoing development and testing.

I've added an entry to our CSS guidlines(2) to outline what I think should be adopted as best practice for direction-sensitive rules in our CSS. The first of these changesets landed for the FTU app(3) - so you can see how this plays out in practice.

Essentially we want to make RTL a 1st-class citizen, not an exception to the rule. This means calling out all implicitly LTR-specific rules and ensuring we don't bury any RTL overrides at the bottom of the stylesheet where they are likely to be overlooked and regressed.

We should be getting some dev help with implementing this, but feel free to start making these changes to any stylesheets you own. I'm sure it will help QA if we can attach before/after, LTR and RTL screenshots as we go.

Please block the appropriate meta bug (see #1) on anything RTL for 2.5.

If you have other ideas of thoughts on any of this, lets discuss here on the list.

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1179459

2. https://wiki.mozilla.org/Gaia/CSS_Guidelines
3. https://bugzilla.mozilla.org/show_bug.cgi?id=1188069

/Sam

[Sam Foster]

For bidi specifically, the main thing we found in v2.2 was the need to distinguish between elements that are UI and need to follow document direction, and elements that are content and should have their direction determined from content and context. Overloading these 2 concepts in one element is basically a non-starter and always leads to trouble.

For example, a header that is both the container for title content (which could be RTL/LTR or both, think contact name or email title) as well as background-image icons (which need to be specifically on the left or right depending on UI direction.) For cases like these we need 2 elements: one for the UI component that might need ltr & rtl rules, and another nested element that has either dir="auto", or a rule with a unicode-bidi: property

Which is to say that this is mostly a markup issue as far as I'm concerned, not really CSS.

[Zibi Braniecki]

That's awesome to see!

I'm excited to help you make RTL first-class citizen in our platform!

Let me know how L10n team can help.
zb.

[Delphine Lebédel]

Has any RTL work started in any teams? I haven't seen anything RTL-related landing. I know we still don't have specs but there are things we know won't change for RTL. I'm worried as this is a 2.5 committed feature.

At this point, I have to admit I don't really see how we're going to make a great RTL experience for 2.5, nor meet the RA date: no specs so test cases can't be written/updated (and just that takes a lot of time), no actual work started and landing, QA understaffed for this, and I could go on...

Does anyone have any thoughts on how we can (or can't) fix this?

[Naoki Hirata]

We hire/get more contributors that do RTL development?  Preferably RTL speakers/writers?

_______________________________________________
dev-gaia mailing list
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-gaia

[Fabien Cazenave]

Here’s the Phoxygen contribution to the RTL/BiDi CSS Guidelines section
that Sam added to the wiki:

https://wiki.mozilla.org/Gaia/CSS_Guidelines

TL;DR:

• in order to mirror UI elements in RTL, some direction-sensitive
rules in CSS can be used, e.g.:
-moz-{margin,padding,border}-{start,end}
{margin,padding,border}-inline-{start,end} (Gecko 41+)

• avoid using 4-value shorthands with margin/padding/border, because
they imply that the left and right edges are different (asymmetrical):
margin: 1rem; /* symmetrical */
margin: 1rem 2rem; /* symmetrical */
margin: 1rem 2rem 3rem; /* symmetrical */
margin: 1rem 2rem 3rem 4rem; /* direction-specific! */
margin: 1rem 2rem 3rem; margin-inline-start: 4rem;

• this cannot be used everywhere: some properties have no start/end
counterpart, and it won’t work with elements carrying a `dir="auto"`
attribute anyway. In such cases, the `html[dir="{ltr,rtl}"]` approach is
the way to go.

Feel free to share your feedback. :-)
Cheers,

:kazé

[Julien Wajsberg]

How about :-moz-dir selectors ? Can we use them (instead of
html[dir=rtl/ltr]) ?

[Fabien Cazenave]

On 16/09/15 14:57, Julien Wajsberg wrote:
> How about :-moz-dir selectors ? Can we use them (instead of
> html[dir=rtl/ltr]) ?
>

They’re mentioned on the Wiki as well, but my advice would be to use
html[dir="{ltr,rtl}"] everywhere.

:-moz-dir() selectors reflect the direction currently applied to the
target element, which can be different from the direction of the main
document element (e.g. for `dir="auto"` or <bdi> children). If you
really want to define style properties that depend on the direction of
the element itself, the “direction-specific” CSS properties
(*-inline-{start,end}) should be a better call when available.

There are (edge) cases where :-moz-dir() are necessary, though. I
remember we had some when working on the SMS app for the 2.0m branch.
And it might be necessary for the web components, too (still working on
that right now).

:kazé