Explicit RTL indication in pure Markdown

Spec
21

Use this css rule:

unicode-bidi:plaintext;

on your element where the rendered markdown.
I’m from Algeria too :upside_down_face:

2 Likes
22

It seems it works. I have tried it in some examples and the result was amazing.

Still I have to apply it on different other elements like lists, table and different mixture of RTL and LTR text.

23

In cases when “first strong character” heuristic is wrong, ideally you want an override that will also be understood by whatever plain-text editor you are using to edit the markdown source.
This is quite important for editing, otherwise the wrong order and “jumping punctuation” make it very annoying to go back and change the text!

Overriding with explicit <div dir=rtl> or some other syntax would probably not do that for any editor? (Dual-pane editors will render it in preview pane, but not source pane.)
Overriding by inserting an LRM / RLM character would work with bidi-friendly editors :tada:
The heuristic usually fails when an RTL sentence starts with LTR word/quotation or vice-versa, so overriding by U+2068 FIRST STRONG ISOLATE … U+2069 POP DIRECTIONAL ISOLATE might work too in an editor (support less common yet). But it might not translate into a browser(?). That’s what <bdi>, nowdays implied by setting dir, is for.

  • Many plain-text editors don’t auto-detect paragraph direction at all :frowning:. E.g. windows Notepad doesn’t, it lets you use left/right Ctrl+Shift to set default direction for whole window but that’s not stored in the text at all! Can’t help in this case.

  • Gnome’s gedit does auto-detect direction of each line separately. So does retext, based on same GTK widgets. I don’t know how many such editors exist, but heavy RTL users probably use them :wink:

  • For web <textarea> inputs, default used to depend on browser but unicode-bidi: plaintext makes modern browsers (it’s CSS3, https://caniuse.com/#feat=mdn-css_properties_unicode-bidi_plaintext) auto-detect direction per line :heart_eyes:

    It might also help rendered output, requiring less invasive changes than dir=auto(?) See https://github.com/gingko/client/issues/78#issuecomment-418448612 for an example of a program where it helped without deeper modifications. Though I don’t fully understand its behavior.

Given an editor that auto-detects direction per line, it’s very helpful to use markdown processors that allows line break in source WITHOUT a line break in the output. Then you can split mixed sentences/paragraphs such into LTR and RTL fragments on separate lines, making editing much easier.

To take this DIscuss for example, it’s pretty sub-optimal for bidi…

  • textarea source editing is all LTR, but styling it unicode-bidi: plaintext in devtools helps!
  • source line breaks force output line breaks. I actually think that’s a right choice for a commenting interface for non-specialist users (this forum being an exception), but for bidi it precludes the line-per-directional-piece hack that makes editing easier (which few users know).
  • output does not auto-detect direction on blocks.
  • inline elements don’t “isolate”, allowing structure to fragment: :broken_heart:
    אאא בבב ccc ddd
    Source logical order here was (using A=א B=ב notation): AAA `BBB ccc` ddd, note how the “directional run” detected by unicode algorithm crosses the element boundary! That was deliberate in the original algorithm, but mostly wrong, and isolates were invented later to fix that.
    • However, note that same problem exists in the textarea editor (independent of “plaintext”), as it can’t understand markdown inline constructs indicate structure.
      I believe forcing isolation for at least some elements eg. literals, is the Right Thing, but it does conflict with the “editor should match output” argument I made above…
  • the only good part is that <div dir=auto> works, but really, how many can you insert manually?