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

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?


On Wed, Oct 14, 2015 at 9:25 PM, Johannes Wilm <johanneswilm@gmail.com>
wrote:

> On 14 Oct 2015 11:51 am, "Koji Ishii" <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