Page MenuHomePhabricator

Option to override CSS flipping
Closed, DeclinedPublic

Description

Currently TemplateStyles decides whether CSS should be flipped based on the difference between wiki and page language. This is sufficient on wikis where non-wiki-language content is mainly on translated content pages (like Meta and MediaWiki.org), but is useless when the templates used on a page are translated each on its own, which is the case for e.g. Commons file pages. An option (attribute for the <templatestyles> tag) could resolve this issue by providing sufficient data (either language code or the direction itself). This raises caching problems (what if the same stylesheet is requested with different directionalities?), but maybe we can just assume it won’t happen (as the intended use case implies it: a template is served in one language on Commons every time if the language not overridden by hand) and simply load the first version appearing on the page.

Event Timeline

Template styles are part of the page content and if interface language has been passed to the templatestyles tag somehow then the parser cache is presumably already split by language so there should not be any caching problem here. Do you want to write a patch for it?

Template styles are part of the page content and if interface language has been passed to the templatestyles tag somehow then the parser cache is presumably already split by language so there should not be any caching problem here.

It’s not really a caching issue (I rephrased the description several times, and seems like forgot to correct it), but may be an issue at technical level: if a page loads the style several times, it’s technically possible to use different directionalities each time. We can make a decision of not caring about it, but that should be deliberate.

Another open question is that whether language code or directionality itself should be passed to the parser tag. The language code is usually more convenient, but sometimes may result in hackish template code (in case the template doesn’t have a language code, only a directionality). I can’t think of such case in real situation, so I’d support passing a language tag.

Do you want to write a patch for it?

I can, although I won’t have much free time in the next few weeks (but I don’t know if anyone else has plans of spreading TemplateStyles on Commons, so it may not be a huge constraint :) ). The above concerns/questions should be addressed before implementation.

It’s not really a caching issue (I rephrased the description several times, and seems like forgot to correct it), but may be an issue at technical level: if a page loads the style several times, it’s technically possible to use different directionalities each time. We can make a decision of not caring about it, but that should be deliberate.

It just needs to be included in the various keys when it's not the default. The selector prefix (and now that rETSTf7bf5a4e23ba: Add "wrapper" attribute to <templatestyles/> has been merged the wrapper) option already do that, the new parameter just needs to follow the same pattern.

Another open question is that whether language code or directionality itself should be passed to the parser tag. The language code is usually more convenient, but sometimes may result in hackish template code (in case the template doesn’t have a language code, only a directionality). I can’t think of such case in real situation, so I’d support passing a language tag.

Yeah, the language would make more sense. If a template uses an ltr/rtl parameter it can just pick two representetive languages.

It’s not really a caching issue (I rephrased the description several times, and seems like forgot to correct it), but may be an issue at technical level: if a page loads the style several times, it’s technically possible to use different directionalities each time. We can make a decision of not caring about it, but that should be deliberate.

It just needs to be included in the various keys when it's not the default. The selector prefix (and now that rETSTf7bf5a4e23ba: Add "wrapper" attribute to <templatestyles/> has been merged the wrapper) option already do that, the new parameter just needs to follow the same pattern.

The issue is the same that’s mentioned in T200632: this task alters the rules themselves, not the selectors (like the above patch), so including two different versions in a single page would cause an even bigger mess than just silently omitting one of them.

The issue is the same that’s mentioned in T200632: this task alters the rules themselves, not the selectors (like the above patch), so including two different versions in a single page would cause an even bigger mess than just silently omitting one of them.

Ah, I see. We could leave that to users to deal with (now that the wrapper attribute is merged it is possible), or we could have a configuration option for automatically prefixing selectors with ltr/rtl (which MediaWiki outputs on all pages). Although making that work together with skin class hoisting (T197617) would be challenging.

In the past months I came up with a much safer idea: instead of passing a language/directionality to TemplateStyles, I included the whole template output in a tag with dir attribute, and added rules like

/* @noflip */
.mytemplate[dir="ltr"] {
	float: right;
}
/* @noflip */
.mytemplate[dir="rtl"] {
	float: left;
}

This way the CSS is the same for any directionality, so there is no issue with multiple inclusions, and also forces the template editor to mark the directionality of the text machine-readably, which is good for accessibility, by the way.