Page MenuHomePhabricator

Review usages of `.mw-content-ltr` and `.mw-content-rtl`
Open, Needs TriagePublicBUG REPORT

Description

We are currently in the process of removing legacy CSS from MediaWiki. In many cases this will significantly reduce the amount of CSS needed to render a MediaWiki page which will lead to better page load times, however may impact articles in one particular way.

If your wiki uses <div class="mw-content-ltr"> or <div class="mw-content-rtl"> without dir or lang attributes, these will currently not work in the Vector modern skin and will soon stop working in future in other skins without action.

''Why'' - this removes 2kb of CSS for every page view, a significant performance gain; it reduces maintenance burden on the engineers of skins; this has never worked on mobile versions of the site.

Action required by 12th August.

1) Check the impact on your wiki.

Go to yourwiki/w/index.php?title=Special:Search&search=insource%3A%2F\<div+class\%3D["']mw-content-(ltr|rtl)["']\>%2F&profile=advanced&fulltext=1&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1

Check the results in the top right corner. If the number is significant (I would suggest. < 1000 may not be significant for guidance), you are impacted.

Also check templates:

Go to yourwiki/w/index.php?search=insource%3A%2F%5C%3Cdiv+class%5C%3D%5B%22%27%5Dmw-content-%28ltr%7Crtl%29%5B%22%27%5D%5C%3E%2F&title=Special:Search&profile=advanced&fulltext=1&ns10=1

Check that no widely used templates appear in that search result.

2) Understand the issue

Click one of the search results to the above query and view in Vector modern by adding the following query string parameter:
?useskin=vector&useskinversion=2

Content will appear in the wrong writing direction.

BrokenWith correct fix
Screen Shot 2021-07-29 at 11.41.07 AM.png (1×2 px, 157 KB)
Screen Shot 2021-07-29 at 11.41.42 AM.png (938×1 px, 124 KB)

3) Fix the issue

Add the following rule to MediaWiki:Common.css (or MediaWiki:(Monobook|Vector).css` if preferred.

/* Short term fix for T287701. Please remove when all templates have `dir` attributes set. */
.mw-content-ltr {
       /* @noflip */
       direction: ltr;
}

.mw-content-rtl {
       /* @noflip */
       direction: rtl;
}

4) Notify users that the dir attribute must be used going forward.

Make sure editors are updated on best practices for including content in a different language / direction and that failure to use them leads to rendering problems on mobile.

For example:

Correct:

<div class="mw-content-ltr" dir="ltr" lang="en">Today's featured article</div>
<div class="mw-content-rtl" dir="rtl" lang="he">ערך מומלץ </div>
<code class="mw-content-ltr" dir="ltr">...</code>

Incorrect:

<div class="mw-content-ltr">Today's featured article</div>
<div class="mw-content-rtl">ערך מומלץ </div>
<code class="mw-content-ltr">...</code>

Further action

Update mw:Directionality_support#Wiki_content documentation accordingly to clarify on dir preference.

Event Timeline

Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)

Actually, exactly one (< 1000) usage in our wiki is in <ref> replacing template, and it has impact on all the articles.

Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)
Jdlrobson moved this task from To Triage to Announce in next Tech/News on the User-notice board.

Note: This currently impacts modern Vector only which is either opt-in or default for wikis who are early adopter to support us finding bugs like this.

Over the next 2 weeks it will impact all skins so the sooner we get this out the better.

How would you like this described in Tech News?
I've drafted this, but I'm unsure if it is complete & accurate (given the limitations of space):

If your wiki uses <div class="mw-content-ltr"> or <div class="mw-content-rtl"> without the required dir attribute, then these will no longer work in 2 weeks. There is a short-term fix that can be added to your local wiki's Common.css page, which is explained at T287701. From now on, all usages should include the full attributes, for example: <div class="mw-content-ltr" dir="ltr" lang="en"> or <div class="mw-content-rtl" dir="rtl" lang="he">. You can find existing examples on your wiki that need to be updated, using the instructions at T287701.

It's not just div. It can be span, code, and more.

It's not in 2 weeks. It already started on the new vector, for example.

It's not just div. It can be span, code, and more.

Perhaps instead say uses the class "mw-content-ltr" in wikitext e.g.. <div ... might be better, but I'd hope anyone who is familiar with templates would be able to understand this nuance.

It's not in 2 weeks. It already started on the new vector, for example.

The new Vector experience is opt-in and bugs are to be expected there. I've checked other wikis that are opt-in by default early adopters and Hebrew Wikipedia seems to be the only wiki that's majorly impacted by this change so I don't think we need to add confusion around the timeframe. The purpose of this message is to make communities aware of this potential issue and allow them to either act reactively or preactively.

By the way, what does lang parameter add here?

By the way, what does lang parameter add here?

https://www.w3.org/International/questions/qa-lang-why is probably the best explanation.

It also looks like this bug has been present on the Hebrew mobile site undetected for the last 10 years.. :(
https://he.m.wikipedia.org/wiki/%D7%9E%D7%97%D7%A9%D7%91#%D7%9C%D7%A7%D7%A8%D7%99%D7%90%D7%94_%D7%A0%D7%95%D7%A1%D7%A4%D7%AA

Question.. while I agree that the class is used incorrectly a lot... and that most of those incorrect usages should be replaced as described.. at the same time, that's not the proper replacement for a correct usage of these classes is it ?

As far as I understand mw-content-ltr is it to be "the direction that the main content is" (not any possible random child of the content). Specifically, the intent of the class back then, was to make sure that you force align elements the same way as the proper content direction, for instance a template generating a fake edit button and ignoring the direction of any subblocks.

So for proper usages, you should be removing .mw-content-ltr from the html and using templates styling target: .mw-body-content[dir=ltr] .myblock. But the mw-parser-text scoping prevents you from targeting that CSS rule I think.

Where does this happen you might ask? I have no direct examples, but I'd assume in things like Commons/Meta, where multiple levels of mixed content directionality is common, yet consistent placing within the main content is still required. You'd have say ltr interface language and main interface, rtl content (causing ltr editsection strings in rtl content), which can then again have a nested ltr section, including a fake edit link, which should follow the direction of the editsection strings....

I have no idea how common a mess like this is these days. It might be that all these situations were cleaned up in alternative ways over the years, but pretty sure that's what the class was for.

Do we need the class at all? The dir attribute correctly sets the text directionality (except for in Internet Explorer and legacy Edge), but MediaWiki styles such as correct margin side for lists currently depend on the class. I’d appreciate if we could get rid of it and make multilingual templates’ source code simpler.

[…] make sure that you force align elements the same way as the proper content direction, for instance a template generating a fake edit button and ignoring the direction of any subblocks.

Why should it? I don’t know what kind of edit button you mean, but usually the outer directionality (floating side, margin etc.) of an element should depend on the immediate context, e.g. if the box is floated to the right in a left-to-right context, it should be floated to the left within a right-to-left subblock on a (left-to-right) file page, or it will lead to even more things like this, where the content is right-to-left, but the box is floated to the same side as if the content was left-to-right.

So for proper usages, you should be removing .mw-content-ltr from the html and using templates styling target: .mw-body-content[dir=ltr] .myblock. But the mw-parser-text scoping prevents you from targeting that CSS rule I think.

If you still want to depend on the directionality of the page in TemplateStyles, you don’t have to do such tricks: just use .myblock, and CSSJanus will take care of flipping the styles on right-to-left pages. (This doesn’t apply to non-TemplateStyles CSS like sitewide styles, gadgets or user styles, but they aren’t scoped either.)

As a note, that recommended search is woefully under-finding content, consider whether you actually want this to go out in 2 weeks. A more appropriate search finds some 500k instances on a wiki that doesn't need to care about it for the most part (disturbingly many)...

As a note, that recommended search is woefully under-finding content, consider whether you actually want this to go out in 2 weeks. A more appropriate search finds some 500k instances on a wiki that doesn't need to care about it for the most part (disturbingly many)...

That search is still throwing up a lot of false positives.

<div class="mw-content-ltr" dir="ltr" lang="en"

is not impacted by this change.

If in doubt, I suggest adding this rule to MediaWiki:Common.css e.g as we did on Hebrew Wikipedia.

o we need the class at all? The dir attribute correctly sets the text directionality

This

Do we need the class at all? The dir attribute correctly sets the text directionality (except for in Internet Explorer and legacy Edge), but MediaWiki styles such as correct margin side for lists currently depend on the class. I’d appreciate if we could get rid of it and make multilingual templates’ source code simpler.

This was my understanding of the class. As far as I can tell from the git history, this rule dates back to a time when Internet Explorer did not support attribute selectors e.g. [lang][dir] {} .

I'm willing to be proved wrong, but I'd be very surprised if there is a legitimate use case for it given dir and lang can be defined in wikitext and will override the parent direction/language.

Please add [[Special:LintErrors]] rules to detect pages that have this issue.

Please add [[Special:LintErrors]] rules to detect pages that have this issue.

Seems like a good idea. Could you file a task under MediaWiki-extensions-Linter as I'm not too familiar with how that extension works or how to add a linting rule?

I modified the task and included an example for <code> tag. I believe code tag should not have a lang attribute; only a dir one. If that is incorrect, please update the task again and educate me.

By the way, what does lang parameter add here?

https://www.w3.org/International/questions/qa-lang-why is probably the best explanation.

It also looks like this bug has been present on the Hebrew mobile site undetected for the last 10 years.. :(
https://he.m.wikipedia.org/wiki/%D7%9E%D7%97%D7%A9%D7%91#%D7%9C%D7%A7%D7%A8%D7%99%D7%90%D7%94_%D7%A0%D7%95%D7%A1%D7%A4%D7%AA

I was informed that this example does not luck lang parameter, only dir parameter. I checked this out in https://he.m.wikipedia.org/w/index.php?title=%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:IKhitron/%D7%98%D7%99%D7%95%D7%98%D7%94&oldid=31982606
Were we wrong? If not, why need anyone the lang parameter for direction stuff at all?

Volker_E renamed this task from Review usages of mw-content-ltr and mw-content-rtl to Review usages of `.mw-content-ltr` and `.mw-content-rtl.Aug 14 2021, 12:33 AM
Volker_E updated the task description. (Show Details)
Volker_E renamed this task from Review usages of `.mw-content-ltr` and `.mw-content-rtl to Review usages of `.mw-content-ltr` and `.mw-content-rtl`.Aug 14 2021, 12:36 AM
Volker_E added a project: I18n.

I modified the task and included an example for <code> tag. I believe code tag should not have a lang attribute; only a dir one.

If you specify the directionality of some text, it’s almost certainly not in the same language as its context. If it contains no natural language content, you should use zxx according to BCP 47 (page 57).

I modified the task and included an example for <code> tag. I believe code tag should not have a lang attribute; only a dir one.

If you specify the directionality of some text, it’s almost certainly not in the same language as its context. If it contains no natural language content, you should use zxx according to BCP 47 (page 57).

Thanks for educating me on this, @Tacsipacsi. I had not seen this used in action so my first reaction was to check to see if any of our source codes use it. Wikibase does but I have not seen it anywhere else.

Are you recommending that if a <code> tag needs a dir (which probably only happens on RTL wikis when they need an LTR section of code inline) that they should specify both dir="ltr" and lang="xzz"?

Actually even those <code> tags would ideally have lang="zxx" attribute that don’t necessarily need a dir attribute (because they are in LTR context). Even though <code> represents a fragment of computer code, I found nothing in the HTML standard that would mandate that <code> elements’ language is implicitly zxx.

Given that yous aid "ideally", I assume that "practically" we may chose not to add the "zxx" lang code to every <code> element for now. And that even when we specify the dir attribute, we would still elect not to specify the lang attribute. This is not ideal, but is much easier to maintain. In reviewing the HTML standard, I did not find anywhere that says the lang attribute must be specified for <code> elements.

Sorry for bothering, but can I get an answer, please? Otherwise, looks like the lang parameter is not needed at all in this task, and without it, the millions of edits that should be done because of this task will be much easier. Thank you.

This is not ideal, but is much easier to maintain.

I don’t think it would be easier to maintain, it’s just easier to migrate to it using bots now. In the long term, I expect no maintenance costs but many benefits by the way of more support by translators, screen readers, Braille translators, or even browsers for non-disabled people, which can select more appropriate fonts.

In reviewing the HTML standard, I did not find anywhere that says the lang attribute must be specified for <code> elements.

It’s not in the HTML standard (at least I couldn’t find anything about it either), but it’s a AA-level criterion of WCAG 2.1, which is the bare minimum we want to achieve in terms of accessibility.

I was informed that this example does not luck lang parameter, only dir parameter. […] Were we wrong? If not, why need anyone the lang parameter for direction stuff at all?

The example does lack the lang attribute for WCAG 2.1 AA-level compliance. It’s not directly connected to this class change, though; changing <div class="mw-content-ltr"> to <div dir="ltr"> won’t worsen the situation.

The example does lack the lang attribute for WCAG 2.1 AA-level compliance. It’s not directly connected to this class change, though; changing <div class="mw-content-ltr"> to <div dir="ltr"> won’t worsen the situation.

So could you explain me, please, what did I wrong in the tests? Thank you.

As I wrote, such edits don’t worsen the situation in terms of web accessibility; the text was and remained inaccessible to people using screen readers, Braille translators and the like. Your tests do their job, they fix the directionality of the text, they simply don’t fix another issue.

As I wrote, such edits don’t worsen the situation in terms of web accessibility; the text was and remained inaccessible to people using screen readers, Braille translators and the like. Your tests do their job, they fix the directionality of the text, they simply don’t fix another issue.

Very well. Could I, please, get one example where adding lang changes something in direction on any device? Thank you.

And one more thing. I tried to fix by your recommendations, and it generally works. But there is a problem, that I couldn't fix until now.
If we use li::marker in references that have direction, it looks differently on different kinds of browsers. For example,
<ref group=hebrew>sometext</ref>
on a page where there were a lot of references in this group looks like this in most of browsers:

Screenshot_20210821-001051_Samsung Internet.jpg (139×826 px, 58 KB)

which is correct, but looks now like that on Chrome and Edge
Screenshot_20210821-001155_WebInspector.jpg (180×656 px, 55 KB)

You can see the numbering in opposite direction. Tried to add

.hebrewRefList li::marker {
    direction: rtl
}

does not help. Tried all the possible values of direction and unicode-bidi, nothing helps. How can I fix this?

Very well. Could I, please, get one example where adding lang changes something in direction on any device? Thank you.

If I understand correctly, the lang attribute does not have any affect on the direction of text. It is not required for this. However it is a useful additional standard piece of markup to include for both semantic reasons and for accessibility reasons (e.g. for screenreaders it might make the "voice" module change to one more suitable for speaking that language). Details about this are explained at https://www.w3.org/WAI/WCAG21/Understanding/language-of-parts.html

Very well. Could I, please, get one example where adding lang changes something in direction on any device? Thank you.

If I understand correctly, the lang attribute does not have any affect on the direction of text. It is not required for this. However it is a useful additional standard piece of markup to include for both semantic reasons and for accessibility reasons (e.g. for screenreaders it might make the "voice" module change to one more suitable for speaking that language). Details about this are explained at https://www.w3.org/WAI/WCAG21/Understanding/language-of-parts.html

So, I was right. I know we need to use it, of course. But not as a part of this task description convertion. Thanks.

And one more thing […]

I could not reproduce this in Chromium 90.0.4430.212 on Debian 10.10 “buster” on Hebrew Wikipedia logged out, using the default new Vector skin. I used the following wiki text:

<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>

<div class="hebrewRefList">
<references group="hebrew" />
</div>

and saw this:

Screenshot from 2021-08-21 14-19-57.png (479×544 px, 28 KB)

And one more thing […]

I could not reproduce this in Chromium 90.0.4430.212 on Debian 10.10 “buster” on Hebrew Wikipedia logged out, using the default new Vector skin. I used the following wiki text:

<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>
<ref group=hebrew>sometext</ref>

<div class="hebrewRefList">
<references group="hebrew" />
</div>

and saw this:

Screenshot from 2021-08-21 14-19-57.png (479×544 px, 28 KB)

I get a lot of complaints. Maybe you should try another Chrome. Because I can't see the problem on Samsung Internet, Chrome derived, either.

Ouch. Getting rid of uses of mw-content-ltr/mw-content-rtl classes (is it planned by this change besides CSS removal?) will impact Convenient-Discussions as it uses (actually, just started to use) these classes to find LTR discussions on RTL pages and vice versa (like this). These discussions are then styled accordingly:

image.png (736×996 px, 94 KB)

The currently used rules look like this (link):

.sitedir-rtl .cd-commentLevel:not(ol) > li,
.sitedir-rtl .cd-commentLevel:not(ol) > dd,
.sitedir-ltr .mw-content-rtl .cd-commentLevel:not(ol) > li,
.sitedir-ltr .mw-content-rtl .cd-commentLevel:not(ol) > dd {
  padding-left: 0;
  padding-right: 1em;
  margin-left: 0;
  margin-right: 1em;
  border-left: 0;
  border-right: 1px solid #c8ccd1;
}

And there's many more of them.

The problem with using [dir="ltr"]/[dir="rtl"] in CSS selectors is that attributes are considered way worse than classes in terms of CSS performance.