Last modified: 2012-06-21 02:39:01 UTC
File CSS is flipped if the direction is RTL. Site CSS is flipped if the direction (ltr/rtl) is different from that of the wiki content language. While this didn't make any difference in 1.17, since 1.18 (see r91518 et al.) it causes flipping. This implied that all site CSS should be checked for rules that need @noflip. I think it makes much more sense to *not* flip site CSS by default, because most style is for content stuff which should not depend on wgLang direction. This is easily changeable in either ResourceLoaderSiteModule or ResourceLoaderWikiModule (?) by adding getFlip() { return false; }, but this would likely require something like @flip or @doflip in CSSJanus (which would behave the other way around as @noflip). (Relevant revision: r84740)
This requires that CSSJanus allow the caller to set the default flip mode (flip by default, or don't flip by default), and recognize @flip as well as @noflip to override this.
Now that modules are loaded in the user language again, is this still an issue? e.g. if an ltr user visits an rtl wiki, or an rtl user visits an ltr wiki, even the site css should be flipped. What we do need to account for is the fact that scripts originating from the wiki (mediawiki:common.js, gadgets?, ..) are likely to be based in RTL (whereas file modules are based in LTR). So the flipping application is triggered differently. The latter is or could be done in the ResourceLoaderWikiModule class, as Robin mentioned briefly. I'm not a big fan of a @flip rule, doesn't make sense to me (yet).
(In reply to comment #2) > Now that modules are loaded in the user language again, is this still an issue? Are you referring to bug 6100? Because solving 6100 had this bug as a consequence. Or is there a recent change I am not aware of? > e.g. if an ltr user visits an rtl wiki, or an rtl user visits an ltr wiki, even > the site css should be flipped. Most often not (and that's what this bug is about), because site CSS is mostly about the content, i.e. needs to follow the direction of the content and not the user language, so they would need to be tagged with @noflip. Most obvious example is the infobox. > I'm not a big fan of a @flip rule, doesn't make sense to me (yet). It is impossible to tag all of the site CSS relating to content with @noflip, that is why I would like to reverse the logic and introduce @flip for site CSS.
(In reply to comment #3) > (In reply to comment #2) > > e.g. if an ltr user visits an rtl wiki, or an rtl user visits an ltr wiki, even > > the site css should be flipped. > > Most often not (and that's what this bug is about), because site CSS is mostly > about the content, i.e. needs to follow the direction of the content and not > the user language, so they would need to be tagged with @noflip. Most obvious > example is the infobox. That assumption is completely wrong. And assuming the opposite is wrong, too. Modules coming from the site-level (common.js, skin.js, gadgets, ) are used for all sorts of things. Personally I believe it is much more common for a gadget to manipulate the interface than to manipulate the article content. Either way, it is a moot point. > > I'm not a big fan of a @flip rule, doesn't make sense to me (yet). > > It is impossible to tag all of the site CSS relating to content with @noflip, > that is why I would like to reverse the logic and introduce @flip for site CSS. We can change the base direction, sure. But we don't need to disable flipping and introduce @flip. The problem is not that you need @flip. @flip is an example of how the actual problem could be solved. The actual problem is that the base direction is assumed wrong (in your opinion). Also, having an example would be great. I think maybe there is a different problem or misunderstanding relevant.
