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

Hey,
I agree with Florian here. This has nothing to do with disabling through
preventDefault. PreventDefault is used within the space of web based
editors mainly to provide JS editor defined behavior to replace undesired
default browser behavior.

If one wants to just forbid IME from accessing a site, one would probably
do some sniffing to see if the user is on a mobile device and additionally
redirect the user to a different address when receiving the first
compositionstart event.

Or to achieve the other behavior where IME just doesn't produce any input,
just cancel the compositionstart, not every single IME-based beforeEdit
event.

Sorry if that was misunderstood.
On 15 Oct 2015 6:56 pm, "Koji Ishii" <kojiishi@gmail.com> wrote:

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