I think the best way to solve this is to define per module the kind of language: page content language or user interface language. For example the file resources/src/mediawiki.skinning/content.css should always use the page content language. This allows to remove all CSS selector dependencies to mw-content-ltr/mw-content-rtl and all /* @noflip */ because the flipping is done by the page content language instead of the user interface language.

This would solve tasks where the page content language differ from the user interface language:

• T126744: Sorting of month names in tables should depend on page content language

I see two possibilities to have modules separate languages for user interface language and page content language.

Example with user interface language de and page content language nl:

Variant 1

Two requests:

1. load.php?lang=de&modules=userinterfacelanguagemodules
2. load.php?lang=nl&modules=pagecontentlanguagemodules

Variant 2

One requests:

1. load.php?lang=de&contlang=nl&modules=userinterfacelanguagemodules|pagecontentlanguagemodules

@Fomafix If I understand correctly, our current approach in stylesheets is to write both the LTR and RTL versions of styles. The original proposal was to introduce a feature to automatically generate the second variation based on the first, and still send both rules to the browser.

I believe you are now proposing to only send one rule to the browser, and have ResourceLoader somehow know what the page content language is.

I think this might not be possible, because a page can have multiple languages (and directions) of content on the same page. However, we do not support multiple interface languages on one page. That is why we can use flipping for interface styles, but not for content styles.

I guess we might have to wait till margin-start got supported by major browsers to solve it?

Ref:

• https://caniuse.com/#search=margin-start
• https://drafts.csswg.org/css-logical/#margin-properties

The main intent is to reduce redundancy on the definition to avoid inconsistencies and mistakes. This can solved on different ways:

1. A special preprocessing which expands the rules. The transferred CSS contains the rules three times like now.
2. Using the current flipping processor but based on the content language instead of the user interface language. On loading the resources the content language or at least the direction of the content language must supplied. This is problematic on pages with several content languages or directions. The rules must separated here by an individual selector and the selector must supplied to the resource loader to integrate the selector in the CSS rules.
3. New CSS standards supports some improvements that allow to specify orientation relative to the language direction. There are the *-start and the *-end properties and the :dir() pseudo classes for selectors. But the browser support is bad and this can only used, when all supported browser supports this.

It is intended to have .mw-editsection in the user interface part and in the content part.

@Fomafix Sorry, I should have explained why I changed that.

I do not believe that styles like this should be separated/duplicated. Most parts of the interface that are language-specific occur only in elements outside the content area.

For cases where we generate content in the user language (such as on most special pages), there the content is still wrapped in an element like mw-content-ltr, hence there would be no need to have a content-less CSS rule. Would you agree?

The selector .mw-editsection is a bad example because it is (mostly) used in content. I currently can not find a usage on a special page. But I'm sure there is one.

Another example is the collapsible toggle button .mw-collapsible-toggle which is used in the content and outside of the content.

The CSS pseudo selector class :dir() would help in all cases. The classes mw-content-ltr and mw-content-rtl together with expanded selector allows to simulate the :dir().

In T89561#3856347, @Fomafix wrote:

2. […] This is problematic on pages with several content languages or directions.

Most pages, including AFAIK all content pages, have only one page language. They may contain content in other langages, but those are children of the same root content element. So I think option 2 is feasible; if a module is to be used on pages with many content languages, the current manual solution with @noflips is still there. The main advantage of option 2 over option 1 is the size: if a module will never be used on multilingual pages, don’t make the ResourceLoader output more than twice as big. For example, the elements styled by the stylesheet introduced in T252524 will always be in the content language. (They contain content with potentially different directionality, but that doesn’t matter here.)