Re: Way forward and IME behavior speccing

Please take a look back at this whole story.

It is too complex.

In order to make a good editor, which works in all modern browsers, one is
not missing much.

Go without contentEditable. Implement your own. Implement your own
selection. Your own character insertion, character deletion, paragraph
creation--everything.

That way, you don't have multiple, complex implementations, which some
people worked very hard on, and end up being not so good and not very
consistent.

I bet browser developers would just love to throw in the towel on this one
and say "web developers, you have the DOM, you have modern UI toolkits, you
have lots of libraries--use them and implement an editable element".

Then, when a basic editable element is implemented in JavaScript, each
editor can decide for itself on the semantics of actions, document schema
and stuff.

I've played around with the idea (https://github.com/mightyiam/vegan) (text
there is very outdated-I have some better ideas in my mind now) and it
works pretty awesome and even if I am missing some required browser API
regarding input, that is just minute in comparison with all what you've
been talking about lately.

Why more complex API? Let the web sort it out. Give the minimum required
and make sure it is consistent cross browser. That's it.

If you'd like to join forces on an editor that implements actual editing,
give me a call. I'm funded. Let's cooperate.

On Wed, Oct 14, 2015 at 12:06 AM Ryosuke Niwa <rniwa@apple.com> wrote:

>
> > On Oct 13, 2015, at 6:14 AM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
> >
> > On Tue, Oct 13, 2015 at 2:29 PM, Koji Ishii <kojiishi@gmail.com> wrote:
> >> I'm feeling that I'm not communicating well on what I wanted to say,
> sorry about that. Let me try to re-phrase.
> >>
> >> In my understanding, we started this work with the ultimate goal of:
> >>
> >> 1. Provide better editing experience to web developers and users.
> >>
> >> To achieve the goal, we figured out that unspec'ed, non-interoperable
> DOM operations occur in browsers today, and a lot of editor developer's
> time and efforts are spent to fight with it. So this group set the
> secondary goal as:
> >>
> >> 2. Avoid unspec'ed, non-interoperable DOM operations in browsers during
> the editing operations.
> >>
> >> With that achieved, editor developers can use their time and efforts to
> make better editors, so we consider this can help the goal 1.
> >>
> >> At some point, we started discussing slightly modified goal as:
> >>
> >> 3. Avoid browsers messing with DOM **at all**.
> >>
> >> This goal is different from the goal 2 in that, the goal 2 selectively
> allows DOM operations if it doesn't bother editor developers, or things
> work interoperably, while the goal 3 prohibits every single operation.
> >
> > This was the idea with the beforeEdit/beforeInput event that could be
> preventDefaulted. It was so that the JS editors could define the behavior
> and take this away from the browsers.
> >
> > All uncontrolled and non-preventable DOM modifications do bother the
> editor developers per definition, because it means that the structure of
> DOM and the underlying document model no longer are in Synch. All major
> editors either already have or are currently moving to a model where they
> no longer use the representation in the DOM as being the same as the
> document that is being edited.
>
> That, I agree.
>
> > However, I don't think we should just create a situation that barely
> works for JS editors by circumventing what the browser does and rolling
> back changes it mistakenly introduces. That makes the creation of even a
> very basic editor just much more complicated.
>
> Right.
>
>
> > On Oct 13, 2015, at 1:20 AM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
> >
> > A) In this new mode we continue to entirely forbid IMEs to deal with
> more than just the contents of a text node. If the IMEs are unaware of DOM
> structures, then surely this must be in the browser code that glues it to
> IMEs. The user experience will be slightly worse for a few cases (auto
> correct will not work on partially styled words), but it will be a major
> improvement for all other cases and it will do that JS editors will not
> just break randomly when dealing with IMEs.
>
> This is not acceptable because it would significantly hinders user's
> ability to edit text.
>
> > B) We make all of these IME-introduced changes preventDefault'able. IMEs
> will just have to be able to handle this if they want to be standards
> compliant. Also, may not a lot of this be doable creatively in the
> glue-code? If the IME doesn't allow preventDefault, but the default action
> is canceled in JS, couldn't the glue code simply abort the current IME
> operation (tell the IME that composition has been finished) and then start
> it again immediately thereafter and starting out with the text as it is
> after the JS defined operation. To the JS code that would make it look as
> if IME input would be preventDefaultable.
>
> This is probably possible because browsers do have the capability to
> cancel the current composition as needed on both Mac and Windows (and
> likely Linux).
>
>
> While thinking about this problem, I realized there was one more issue
> with the current API.  In WebKit, we need to be able to track which text
> was typed/modified by the user for spellchecking purposes so that when an
> user reverts an correction, for example, we don't try to autocorrect again.
>
> So there needs to be some mechanism for editors to communicate back to the
> browser about where the user typed text moved into.  If we came up with
> some generic API to do that, we might be able to let a Web app handle
> insertions/deletion/etc... initiated by IME, let the app report back where
> the text got inserted, and style text accordingly (for IME and
> spellchecking).
>
> - R. Niwa
>
>
>