Re: Way forward and IME behavior speccing

On Mon, Oct 12, 2015 at 11:06 PM, Florian Rivoal <florian@rivoal.net> wrote:

>
> > On 12 Oct 2015, at 21:46, Koji Ishii <kojiishi@gmail.com> wrote:
> >
> > I basically agree with rniwa. Let's focus on things that bothers editor
> JS developers today. "Not messing DOM at all" itself shouldn't be our goal,
> it should be "only where it really bothers."
>
> This seems contradictory. "Messing with the DOM" is bothering JS editor
> developers today, because then the DOM becomes inconsistent with their
> internal model. For example, implementing "undo" if you were the one doing
> all the changes to the DOM is much easier than if you also have to watch
> the dom in case something else changes it, and reconstruct these changes
> into steps that can be undone.
>

You're right, but it's not contradicting. We need to avoid "messing with
the DOM" where JS developers need to undo. Do we know where JS undoes what
IME did? We can add sentences to define that then, but "at all" is not
required to help JS developers.

> Also let's not worry too much on future, today's IME API cannot submit
> HTML. Fixing is easier than preventing.
>
> Do you mean we can design the the API in a way that does not allow IMEs to
> submit HTML? That would make the design much simpler (like the one we
> agreed to in Paris).
>

Others may know better, but to my knowledge, IME APIs only allow plain
text. Maybe we need someone more familiar with recent IME APIs including
iOS and Android?

/koji