issues with RTL alignment

[eyaler]

thanks for this awesome code. i wanted to use it for my non-code-highlighting use case involving RTL languages, and found the following issues:

1. displayed text is always left-aligned. using ctrl+right-shift or alt-shift the change the text direction (alignment) and/or the language does not affect displayed text.
2. due to the above, selection and highlighting of right aligned text is broken. the hidden correctly-aligned text is highlighted instead. this is relevant for both user selection process itself which is confusing, and the highlighting of that selection or of the browser's find in page. strange crossovers can occur for long lines. see image:

3. also, using dir="rtl" or dir="auto" have no effect (i only tried this with the css-tricks demo)

[WebCoder49]

Thanks for pointing this out! The problem appears to be that the HTML dir attribute is not synchronised between the editable textarea and displayed pre code elements. Also, some highlighting libraries (thinking Prism.js, highlight.js) in the pre code may not work properly with RTL align (requires testing).

My status: I'm afraid I'm very busy right now until 21 June. I can't implement new feature requests or bugfixes myself in projects I maintain, but can merge contributions by others, especially if they fix bugs.

[WebCoder49-temp]

@eyaler It turns out RTL support can be enabled by adding an extra line of CSS.

However, I have yet to fix language support completely because:

• In implementing this, I discovered another bug in my Firefox and WebKit but not Chromium: bold text in Hebrew (which you appear to use, right-to-left) and Hindi (left-to-right) scripts doesn't align correctly between the display and input elements while Arabic (right-to-left), Latin (left-to-right) and Han (left-to-right) work perfectly in all tested browsers.
• I quite carelessly hardcoded the accessible description text (visible when keyboard navigating to a tab-for-indentation-enabled code-input element) as English. I'll start a strings file and detect the language of parent elements to translate.

Fixing this for internationalisation will be a rather key target for me because although programming languages are pretty much always in English, applications using e.g. Markdown and outside of programming applications and the aim to closely match textareas will need it. (Let's make free/open source software bring benefits to people whatever their language and make a more collaborative, equitable, peaceful world!)

[WebCoder49-temp]

I won't be able to release this formally until in about a week's time because of the note in the bio of this account.

[WebCoder49-temp]

@eyaler The Hebrew/Hindi bold text bug can be fixed by importing and using a font face like GNU Unifont which covers regular and bold monospaced (or any kind for that matter, as long as regular and bold have the same width) styles for all the scripts you are using. Alternatively there may be a way to make Firefox render bold characters in the same way Chromium does it so they are the same width and the underlying operating system font doesn't make a difference, but I don't know of a way to do so yet. If you are going to use Unifont specifically, though, you should be aware of its slightly-pixelated-console appearance, which may or may not be what you are going for:

Please let me know what you've chosen - thanks!

For fixing this bug more comprehensively, it would be helpful if you could let me know if you can reproduce this bug (without Unifont) on all the browsers you have and let me know the browsers, versions, and operating system/font configuration you're using.

[WebCoder49-temp]

...of course another "solution" for the inconsistent-width is to only use normal font-weight in your Prism.js/highlight.js style.

[eyaler]

@WebCoder49 @WebCoder49-temp thank you so much for looking into this!

here is a screen shot from your i18n-contents/i18n.html where i selected the text and then pressed Ctrl+Left-Shift to align the text left. as you can see the discrepancy still shows.

if you inspect you will see that the keystroke above changes the textarea dir to "ltr".

to fix you can add:

code-input textarea[dir=auto] + pre {
    unicode-bidi: plaintext;
}

code-input textarea[dir=ltr] + pre {
    direction: ltr;
}

code-input textarea[dir=rtl] + pre {
    direction: rtl;
}

and this seems to solve the issue! tested in firefox and edge on windows. i am a bit weary about the dir=auto solution but initial tests look ok. lmk if its relevant to do a PR

as regard to bold text - i guess this is font dependent, and also may depend on using an actual bold font vs browser approximated bold (which may explain the browser difference you are seeing)

[WebCoder49-temp]

@eyaler thanks for this and sorry - I'm quite tired (but love programming as an antidote) right now and completely ignored the wording of your issue when looking at it yesterday! A pull request would be very welcome but please be aware that due to the account issues I won't be able to release it via GitHub's system yet (but will be able to merge it now into my i18n-contents branch, test it then move it to main).

Just now I have got the UI for plugins to be localisable and the accessible keyboard navigation description to display correctly for right-to-left content, which will be released at the same time.

[eyaler]

sure. btw, testing this i ran into a firefox-specific vanilla textarea issue with dir=auto (not specific to this repo): https://bugzilla.mozilla.org/show_bug.cgi?id=1973355

[WebCoder49]

Thank you so much for this, @eyaler!

[WebCoder49]

Hello again! There's no need to submit a PR now as I've committed the change but with you as the commit author (and me as the committer). I'll release the fixes now; thank you very much for the support and nudge to make code-input more internationalised!