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

On Thu, Oct 15, 2015 at 10:17 PM, Florian Rivoal <florian@rivoal.net> wrote:
>>
>> 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.

I'm all good to make the fix easier, but preventDefault is not a tool
to fix, it's a tool to disable certain actions.

If a best-ever editor is broken for, say, Vietnamese, I do not want
editors to disable Vietnamese. Leave it broken, just say it doesn't
support it, and Vietnamese IME developers may be able to fix it.

You're right that single person cannot fix the whole world, I
completely agree with that. If you can't fix, leave it broken and keep
the door open, so that other people can help to fix. In the world of
Open Web, something is broken for someone, but anyone can jump in to
help. IME developers want to make their IME better as much as editor
developers want their editors better.

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

IME is as important as keyboard. I actually think it's just a software
keyboard. How do you edit without keyboard? IME is not the same level
as cut & paste.

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

Thank you for the explanation, I wasn't aware of the strategy change.
I see a few questions here.

First, the proposal was that supporting every IME is so hard burden
that editors want to cancel them as needed. How such an editor can
handle IME events correctly? Handling IME events are so hard. Wouldn't
the world you explained just create editors that do not handle IME
correctly?

Second. I think this TF started with ce=events because it gives full
control to JS, but then people found that it's too hard for JS to
handle all IME events correctly, so we moved to ce=typing to let the
browsers do the hard part. IIUC what you said, we're now back to
ce=events only for typing through IME while ce=typing for typing
through hardware keyboard, correct? And now we're saying IME is too
hard. Yes it's hard, so we avoided to handle last year. Aren't we
looping?

To me, the move from ce=events to ce=typing is sensible, but moving
back to ce=events is not.

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

I agree this part. We will never be able to do that, so let's not even
try to do this.

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

I don't get this part. I saw Johaness talking about shadow DOM for his
collaborative editor design. Are you talking about collaborative
editors, not about normal editors?

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

So is this discussion all about collaborative editors? And one of
architecture designs of collaborative editors want to use Shadow DOM,
and the design needs to cancel IME events. I understand that and
already recommended to take different routes if it requires the change
he proposed.

I'm not sure how that discussion is connected to preventDefault IME
events discussion. Can you shed me a light?

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

I think the basic assumption mentioned above is different between you
and me. IME is not a feature, it's a keyboard, it's about typing.
Defining all IME events in a cross-platform way, and JS to handle them
properly, will never happen. Let browsers to handle them, just like
browsers handle hardware keyboard.

What we should do instead is to understand what could happen
differently from hardware keyboard, abstract if necessary, and deal
with it. We will need to learn what IME API can do on each platform,
but I don't think we can avoid that whichever way we go.

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

True, js is not in control of IME, in the same manner as it is not in
control of Caps Lock for instance. We need to accept Caps Lock exists,
we can ask its status if needed, but don't try to control it. Pioneers
tried to control IME and gave up because it was too hard last year.
Let's not come back there. You will face too much troubles if you try.

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

I don't think we accept typing and add to DOM while JS is running, DOM
is not multi-thread aware, so don't worry about this.

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

Great idea. Ideally we'd like to talk on Monday so that the discussion
can be taken into WPWG on Tuesday, but even if could not, as Art
suggested, I think we should have a slot in WPWG and explain the
current status there. IIUC, TF can't make resolutions, but proposals,
and need to get WG resolutions, so keeping WG up-to-date is good I
think. Can you or Johannes make this happen?

/koji

Received on Thursday, 15 October 2015 16:56:43 UTC