Wikimedia Bugzilla is closed!

Even though very recent browsers implement different ways of dealing with RTL/LTR, Wikimedia projects have a very large userbase with older and even out of support browsers. Removing these concepts from our codebase now, would mean that we introduce more problems for those users. I don't think this is the right thing to do right now. Maybe in a few years. We're conservative where it comes to backwards compatibility for browsers.

(In reply to comment #0)
> AFAICS it is easy/possible to remove these usages by replacing them with
> suitable HTML tags and CSS styles.

Not necessarily.

There are several issues here:

1. HTML5 gives more robust solutions for some of use cases of RLE, RLM etc., for example bidi isolation. We already use it here and there in MediaWiki code, for example in citation numbers As Siebrand says, however, this should be done gradually and carefully, and we shouldn't just drop support for browsers that don't implement these features.

2. In some cases, RLE/PDF is just a requirement. For example, it's impossible to define the direction of element tooltips (the title tag), and W3C actually recommends using RLE|LRE/PDF for this.

3. getDirMark can be replaced by getDirMarkEntity wherever possible. It should make it easier to debug, if nothing else.

Totally agree use of lrm rlm in MediaWiki but using unicode-bidi per http://reference.sitepoint.com/css/unicode-bidi is supported in IE. "Internet Explorer for Windows versions up to and including 7 have some serious bugs relating to floated elements used in combination with the declarations direction: rtl; and unicode-bidi: embed;.". In fact I wanted a same this commit https://github.com/ebraminio/commafeed/commit/315d5705ccb37ab71b418357587b2a14b9f7c3b4 for MediaWiki. In fact using lrm and rlm and more buggier than using unicode-bidi: embed;
I found this bug https://crbug.com/152650 on MediaWiki recent changes:

just paste this in Chrome url to see what is my problem: data:text/html;charset=utf-8,%D8%A8‏.....%D8%A8
compare it with: data:text/html;charset=utf-8,%D8%A8.....%D8%A8

*in MediaWiki -> in document.title

(In reply to comment #3)
> Totally agree use of lrm rlm in MediaWiki but using unicode-bidi per
> http://reference.sitepoint.com/css/unicode-bidi is supported in IE.

IE support unicode-bidi: embed, but not unicode-bidi: isolate. To test, see
https://en.wikipedia.org/wiki/User:Amire80/bidi-isolate

> "Internet
> Explorer for Windows versions up to and including 7 have some serious bugs
> relating to floated elements used in combination with the declarations
> direction: rtl; and unicode-bidi: embed;.". In fact I wanted a same this
> commit
> https://github.com/ebraminio/commafeed/commit/
> 315d5705ccb37ab71b418357587b2a14b9f7c3b4

I commented there.

> for MediaWiki. In fact using lrm and rlm and more buggier than using
> unicode-bidi: embed;
> I found this bug https://crbug.com/152650 on MediaWiki recent changes:
> 
> just paste this in Chrome url to see what is my problem:
> data:text/html;charset=utf-8,%D8%A8‏.....%D8%A8
> compare it with: data:text/html;charset=utf-8,%D8%A8.....%D8%A8

Both of them display the same result in Chrome and in Firefox: Ba, five does, Ba.

(In reply to comment #5)
> IE support unicode-bidi: embed, but not unicode-bidi: isolate. To test, see
> https://en.wikipedia.org/wiki/User:Amire80/bidi-isolate

In fact I've did a patch locally http://fa.wikipedia.org/w/index.php?diff=10477876 against it, because it was making problem when you see you put rtl summary on ltr section title (like http://fa.wikipedia.org/w/index.php?title=%D9%88%DB%8C%DA%A9%DB%8C%E2%80%8C%D9%BE%D8%AF%DB%8C%D8%A7:%D9%86%D8%B8%D8%B1%D8%AE%D9%88%D8%A7%D9%87%DB%8C_%D8%AF%D8%B1%D8%A8%D8%A7%D8%B1%D9%87%D9%94_%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87_%D8%A7%D8%B2_%D9%82%D9%84%D9%85_%D8%AA%D9%88%DA%A9%D8%A7%D8%B1/%D9%BE%D8%B1%D8%B7%D8%B1%D9%81%D8%AF%D8%A7%D8%B1%D8%AA%D8%B1%DB%8C%D9%86_%D9%82%D9%84%D9%85%E2%80%8C%D9%87%D8%A7_%D8%A8%D8%B1%D8%A7%DB%8C_%D9%85%D8%B7%D8%A7%D9%84%D8%B9%D9%87_%D9%88%D8%A8&action=history Tahoma, Iranian sans, ..., put unicode-bidi: isolate there to see what will happen).

> I commented there.
That commit was in fact two commit, instead of just folding whitespaces before lrm, I removed ltr because with unicode-bidi: embed; was not needed. You shall test before comment there anyway

> Both of them display the same result in Chrome and in Firefox: Ba, five does,
> Ba.
Yes, test it on Windows

(In reply to comment #6)
> In fact I've did a patch locally
> http://fa.wikipedia.org/w/index.php?diff=10477876 against it, because it was
> making problem when you see you put rtl summary on ltr section title (like
> http://fa.wikipedia.org/w/index.

This is a bug that is worth reporting separately. Can you please report it?

(In reply to comment #7)
> This is a bug that is worth reporting separately. Can you please report it?
Please file it I am not very optimistic about filing bug on wikimedia bugzilla (for example this bug was stale for one year). Also another interesting bug like is .blockExpiry { direction: ltr; } see http://fa.wikipedia.org/wiki/%D9%88%DB%8C%DA%98%D9%87:%D8%B3%DB%8C%D8%A7%D9%87%D9%87%E2%80%8C%D9%87%D8%A7/block <span class="blockExpiry" dir="ltr" title="1 day">۱ روز</span> is simply wrong . I just fixed that locally to prevent filing bug on wmf bugzilla

Also see http://browsershots.org/http://tools.wmflabs.org/fatestwiki/crbug260102.html for Windows Chrome screenshots

The related Chrome bug is fixed