- From: Florian Rivoal <florian@rivoal.net>
- Date: Thu, 15 Oct 2015 22:17:33 +0900
- To: Koji Ishii <kojiishi@gmail.com>
- Cc: Johannes Wilm <johanneswilm@gmail.com>, Ryosuke Niwa <rniwa@apple.com>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>, Piotr KoszuliĆski <p.koszulinski@cksource.com>, Takayoshi Kochi <kochi@chromium.org>
> > On 15 Oct 2015, at 18:45, Koji Ishii <kojiishi@gmail.com> wrote: > > On Thu, Oct 15, 2015 at 3:16 PM, Florian Rivoal <florian@rivoal.net> wrote: > >> I also completely disagree with your statement that the discussions here >> about potential limits to what browsers can do to the DOM in the context of >> IME do a disservice to minorities (to the extend we can even consider the >> CJK world a minority). I believe it is doing the very opposite. > > Did you read the (exaggerated) example? Yes. The way I read it, the point is that if working with IMEs is easy, js based editors will do it, but if it is not, they won't. Because even if they would like to accommodate for all languages in the world, if the amount of effort that it takes to do so is out of proportion with the business they can get out of it, then they cannot justify the investment. They would not be breaking the browsers' native editing experience. That is already a broken mess. They are trying to fix it, and the question is whether we make it easy for them to fix it for everyone or not. >> By imposing some restrictions on what IME can do to the DOM, just like we >> are imposing restrictions on what every other editing operation by driven >> the UA can do to the DOM, we make it possible for js editors to work with >> IMEs, and actually support these languages. > > The proposal said "all" and "every single" while you said "some". Can > you list what your "some" includes? IMEs are important, but IME are not more important than everything. We are talking about a mode where carets movements do no happen unless javascript is explicitly making them happen. Where pressing backspace or delete does nothing without the intervention of JS. Where the spell checker or auto correct or cut&paste only worth through js. We are not singling out IMEs as a thing that should be restricted. We are trying to find a way to make sure that anything the IME does either has to go through js to effect any change, or can be made to go through js, just like everything else. Since it seems unlikely that we can in the short term come of with enough low level events to describe everything an IME could possibly want to do, the path proposed by Johannes is to let the js react to the composition-start event and move the composition to some place else, (DOM, shadow DOM...). To make this possible, we may need to restrict IMEs to only work on plain text. This may mean, as discussed with Ryosuke, that we also need to add some form of event or API letting to let the IME inform the js that it wants to reconvert a word, and let the js deal with providing the IME with that word, even if it means it has to extract it from the markup. But it does not mean that IME should be the only thing that gets to bypass the entire system, thereby making it fail its goal of protecting the consistency between the js editors' internal model and the DOM. >> The alternative, as is frequently seen today, is that js editors will >> frequently either ignore what IMEs can do and simply fail to work correctly >> when they are used, or even be implemented without using contentEditable at >> all, making IMEs impossible to even activate. Neither of which is better for >> the users of languages that require an IME. > > I think it's better. Please read my last comment. When comparing the > two, today, things are broken. With the proposal, things are > prohibited. How do they differ? The proposal is not about prohibiting IMEs so that they don't work in editors. Not anymore than it is about building editors where caret movements are impossible, or where deletion is impossible. This is about exposing APIs so the browser exposes user intent and provides some infrastructure so that an full featured editor can be built in javascript. Which implies that javascript is in charge. Of everything. Using browser-provided APIs, yes, but the browser does not provide an editor. It merely provides some of the building blocks of an editor. >> It is precisely because js based editors want to deal with IMEs graciously >> that they want to have control over IMEs. Far from discriminating against >> minorities, they want browsers to stop making it so hard to support them. > > "Deal with" is good with me. "Control" depends on what you want to > control, appreciate if you can list them. The proposal wants to > "prohibit" or "cancel." That looks different to me. If IMEs can make changes to the document despite the js wanting them not to, then js is not in control. The reason why js might not want them to is not out of prejudice against IMEs in particular, but because it is preventing ANY change to the document that doesn't go through itself. If JS is in the middle of synchronizing the DOM between two documents over the network, if it is in the middle of applying an undo, or ..., then it has perfectly legitimate reasons to prevent any changes from hitting the DOM, including (but not limited to) IMEs. So far in the model we've been discussing, everything else is preventable. If you're still not convinced, I suggest we try to resolve our differences over a beer (or any other beverage of your choice) when we meet in Sapporo. Mails do not seem to be overly conductive of the type of discussion we are trying to have. - Florian
Received on Thursday, 15 October 2015 13:18:06 UTC