- From: Koji Ishii <kojiishi@gmail.com>
- Date: Thu, 15 Oct 2015 18:45:31 +0900
- To: Florian Rivoal <florian@rivoal.net>
- 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 Thu, Oct 15, 2015 at 3:16 PM, Florian Rivoal <florian@rivoal.net> wrote: > > Recognizing that browsers vendors have, over the course of many years, > decided not to invest the substantial amount of resources it would take to > make contentEditable, execcommand and related APIs sufficiently powerful and > interoperable to address the needs of editing of the web, we set out to > define a minimum set of APIs/attributes/events/... which do not, by > themselves, provide these capabilities, but do allow a javascript based > editors to do so. I'm completely fine with what you 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? > 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? > 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? > 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. /koji
Received on Thursday, 15 October 2015 09:46:20 UTC