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

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