Change RTL detection to rely on unicode-bidi paragraph by paragraph

[Gargron]

Ref: https://discourse.joinmastodon.org/t/improve-bidi-support-a-better-support-for-rtl/2876

[ahangarha]

I think this shouldn't be applied for all links but links such as mentions and hashtags.

[Gargron]

But all links are ascii (https://...)

[ClearlyClaire]

Not necessarily. Mastodon allows links with arbitrary text from other software.

[Gargron]

I would wager that the majority of links would be ascii URLs and we'll have consistently better results by not making them affect the directionality of the whole post.

[ahangarha]

Is there any way to bring a live instance with these changes so I test multiple possible scenarios?

[ClearlyClaire]

It might not be well-supported in Safari: https://caniuse.com/#feat=mdn-css_properties_unicode-bidi_plaintext

[Gargron]

Okay, so I see two options here. Maybe we can get away with this not working in Safari, who knows how many Safari users we have that would be affected by this (directionality of the posts would be affected by interface language, so if you use the UI in a right-to-left language, you'd see posts right-to-left as well). Or maybe we keep the flawed detection code and the dir attributes and hopefully the unicode-bidi property overrides that when the browser supports it.

[ClearlyClaire]

Okay, so I see two options here. Maybe we can get away with this not working in Safari, who knows how many Safari users we have that would be affected by this (directionality of the posts would be affected by interface language, so if you use the UI in a right-to-left language, you'd see posts right-to-left as well).

It could be ok, but I'm not sure…

Or maybe we keep the flawed detection code and the dir attributes and hopefully the unicode-bidi property overrides that when the browser supports it.

If I understand the specs correctly, the plaintext and isolate values would indeed override the dir attributes where supported.

That being said, the spec says “Authors should not use unicode-bidi in HTML documents.”

An alternative could be to not set the direction on toots, and wrap them and each of their <p> in a <bdi>

[Gargron]

I have heard that dir="auto" takes care of detecting text direction in input elements. So, rtl.js can be fully removed.

I'm in favour of relying on browser support here.

[ahangarha]

Using 'dir=auto' will handle everything but excluding mentions in the beginning of the paragraph.

[Gargron]

My motivation here is that #15218 seems to indicate some kind of recursion error in the isRtl JavaScript function (though I fail to see it). This PR is a one stone two birds kind of deal in that regard.

[ahangarha]

Great. Counting seconds to see this change on instances.

Thank you

[ahangarha]

I have noticed a little issue when the language is set to Persian (and for sure other RTL ones) which is making little issue with links starting with LTR characters.

This can be solved by adding direction: initial; to .reply-indicator__content p, .status__content p and set unicode-bidi: initial; for .reply-indicator__content a, .status__content a

Test this toot: https://mas.to/web/statuses/105419096662730287

and it seems we need this as well to make sure mentions would render properly:

.h-card {
    unicode-bidi: plaintext;
}

and this is the result in both RTL and LTR direction:

sum up:

These are the fix:

.reply-indicator__content p, .status__content p {
    direction: initial;
}

.reply-indicator__content a, .status__content a {
    unicode-bidi: initial;
}

.h-card {
    unicode-bidi: plaintext;
}