Re: High-level goals and objectives of the Editing TF (was Way forward and IME behavior speccing

> On 15 Oct 2015, at 12:51, Koji Ishii <kojiishi@gmail.com> wrote:
> 
> Thank you for bringing this to a higher level discussion, it is what I was wishing so much. I think this is a big change in the overall direction of the TF, and it needs a resolution at WG level. If we're going that way, can you check with Art or W3C team staff if if it's needed, and how if so?

I think this is completely consistent with the overall direction this TF has had from the very start.

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 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.

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 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.

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.

 - Florian


> On Wed, Oct 14, 2015 at 9:25 PM, Johannes Wilm <johanneswilm@gmail.com <mailto:johanneswilm@gmail.com>> wrote:
> On 14 Oct 2015 11:51 am, "Koji Ishii" <kojiishi@gmail.com <mailto:kojiishi@gmail.com>> wrote:
> > It's clearly a plus, without any minus, for non-IME users. But for IME users, is it really a plus? That'd be a hard comparison, we need to know what issues JS can't work out today, and we need to know what IME features JS wants to disable.
> 
> I think it will be a plus even if only limited features are available, but I am all for more advanced features if we can preventDefault and get them to behave predictably.
> 
> Take the situation now, and lets say I wanted to create an academic editor such as Fidus Writer under profit maximizing conditions:
> 
> I notice IME input seems to have "a life of it's own" and because of that the complexity of my app grows manyfold. So I ask my Chinese and Japanese friends how important it is for them. They tell me that good scientific articles of middle class and richer students will be written in English anyway. Then I notice that on Android everything is IME. But I also see that except in Subsaharan Africa, Windows 7 is much more used than Android. And also in Subsaharan Africa those with enough cash to be interesting as a market for my company write almost all academic texts on Windows. So my business decision is: forget IME, we are too small to support that.
> 
> The above is an exaggerated example, and I hope noone thinks like that. But people need to look at what their priorities are. And if IME input insists on imposing itself on everything else and it behaves in unpredictable and uncontrollable ways, chances are high editors will either disable it entirely or at least not support it in any meaningful way. You have noticed yourself how that is the case for several of the collaborative editor projects.
> 
> Even as an exaggerated example, I don't think your goal is appropriate for the standardize organization of the Open Web Platform to define as the web standards.
> 
> What you said is completely fair for your business, I understand that. But I don't think standard organizations are going to help your business profit when doing so implies sacrificing minorities.
> 
> Apart from that, compare two words. What happens if we go with preventDefault? Those minorities may come to Android saying the IME is broken. Android may add an API to prevent the preventDefault for the IME. It's quite possible to end up with a never-ending war of taking the control ownership.
> 
> On the other hand, what happens if you did what you said without preventDefault? You might get 3 bugs reports from the world saying it doesn't work in China, Japan, and Africa. You're perfectly fine to say your product does not support them for your business reasons, and resolve as "won't fix."
> 
> So what you're proposing--to make every single IME operation preventDefault-able--does not help your goal. You're already fine.
> 
> /koji
>