- From: Johannes Wilm <notifications@github.com>
- Date: Thu, 11 Jun 2015 02:14:25 -0700
- To: w3c/editing <editing@noreply.github.com>
- Message-ID: <w3c/editing/issues/20/111054253@github.com>
I understand the issue. My understanding is that currently it's quite broken for all of that, right? And for example Japanese is entered horizontally, left-to-right on 99.999% of all websites, correct? I don't think we should go as far as hide information from the JS developers in order to make it impossible for them to not make their app work in non-Latin language contexts. They will likely be able to do so anyway. What would be helpful though would be to make it easy to support other inputs than left-to-right texts. Editors currently need a few hundred "if else" clauses for basic operations and most likely only cover ltr horizontal text. So if most of there normal operations "just work", then it won't be much trouble at all to have a handful of of if-else clauses for rtl-text, vertical text, etc. . After all, these editors want to be used as much as possible, so it's not like they want to purposefully force non-Latin writers to switch to English or leave their editor. Things that could make it easier: As has been pointed out, it is currently common practice to switch the selection several times during an edit operation in the JS. If I understand it right, this causes IMEs to commit partially constructed characters. If such issues can be resolved, I think it will help much more. In the case of Fidus Writer, we became aware of the problem of character construction with Brazilian Mac OS X users, as Spanish/Portuguese/German, etc. on Mac seem to use a process similar to IME to construct characters (for example ~ + n = ñ). It wasn't that we didn't want to solve it. It was just that there were already so many issues to work around, so we didn't think it was worth adding the extra complexity needed to leave the selection after just one "~" had been typed on platforms where that may be part of a composition. I think it is important that this is a real compromise: The browser makers get to define their way of handling the caret and deal with bi-di, and non-Latin text directions which the JS editor creator CAN make use of. At the same time the JS editor creators are allowed to deal with the caret handling, including dealing with the different text directions, themselves. --- Reply to this email directly or view it on GitHub: https://github.com/w3c/editing/issues/20#issuecomment-111054253
Received on Thursday, 11 June 2015 09:14:57 UTC