Re: Way forward and IME behavior speccing

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.

My understanding was that we all new this when we started out on this. If
it is news to browser developers, it's probably to a large extend the fault
of us JS developers for not having communicated better how editors actually
work. I tried to explain this in the diagrams I made [1]. Also Frederico
from CKeditor blogged about this recently [2]. Google Docs and Microsoft
365 Online have gone away from contenteditable a long time ago. Gmail has
contenteditable, but also keeps its document model apart from what can be
seen in the browser.

Now there are almost always ways of getting things to work despite the
brokenness of contentEditable. For example, one can simply try to copy the
contents of the DOM inbetween each edit operation, and then create a diff
after any new edit operation with a specialized library for that, such as
diffDOM [3]. I would expect that commercial projects such as TinyMCE or
CKeditor will simply do that to get aorund the weirdness of cE. Just like
they tend to just turn the built-in spellchecking off entirely because it
does weird things to the DOM that cannot be configured nor prevented.

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.


> And this proposal, IIUC, is:
>
> 4. Forbid IMEs do too much work to achieve the goal 3.
>
> I see the current discussions are about how important 4 is to make 3 to
> happen. I think I understand that.
>
> What I don't clearly understand are:
>
> A. Is the goal 3 really required to make goal 2?
> B. When the goal 4 was achieved, can we really achieve the goal 1?
>


>
> Ben rejected the idea of atomic IME commits and making all compositions
> invisible to JS because, while he acknowledged that it helps editor
> developers, he thought it contradicts with the goal 1. Unfortunately we
> don't have reps from MS at this moment, but if we consider his opinion is
> still valid, MS is against the goal 3 and 4.
>

We do have an MS rep here who was also at the F2F. There was nothing
mentioned about MS being against 3 or 4.

It seems like we continue with the same two very different ideas of editors
and what can imrpove them:

1. Browser developers think they can add a ton of bells and whistles and
"smart" behavior to the editors and that translates directly into better
user behavior.

2. JS editor developers see the entire mix of bells and whistles that work
differently in every browser and many times not at all in combination and
so instead of making use of them, they try to find ways to disable or
circumvent the "features" to provide at least an acceptable editing
environment to their users.



> Also, IME is doing all the work for some good sake. I understand
> forbidding some behaviors gives better control for editors, but if our
> conclusion is to get something by disabling some IME features, we need to
> carefully review whether it really provides better experience or not in
> total. It'd be time consuming and a hard way, and we know MS will not
> agree, so we miss goal 2 anyway.
>

I don't think that we know that about MS.

And if the IMEs don't know about HTML and DOM, then surely it must be the
wrapper code or the glue in the browser that unifies the contents of
several text nodes and sends that over to the IME. If that is the case,
this change should be something that could be changed in the glue-code,
right? On the other hand, if IMEs are aware of HTML structure, then that is
a field that should be specced and standardized, just like everything else
web-related.


> So I'm asking, let's try to forget goal 2, 3, and 4 once, and ask
> ourselves that, is what you're proposing the only way to achieve the goal
> 1? Isn't there any other ways by modifying goal 2, 3, or 4 and still
> achieve the goal 1?
>


Yes, so the thing is that the editor projects out there have been developed
for more than a decade. I myself have been working on one sicne 2012, many
of the others have been working much longer on theirs. And I don't think
any of them come to the conclusion at this time that we should just let the
browser handle editing because then it will be nice and smooth. Quite on
the contrary. That's one of the principal reasons why this taskforce was
started.

Now keep in mind that exposing primitives is just meant as the first step.
The goal of eventually -- in 2, 5 , 10, 50 or 250 years -- to have a fully
working execCommand spec that is implemented and working well in all
browsers is still not off the table. It's just not where we start now, The
first step is that we get a limited but working model. Later steps will
then improve upon that.


[1] https://github.com/w3c/uievents/issues/5#issuecomment-137559461
[2]
https://medium.com/content-uneditable/ckeditor-5-the-future-of-rich-text-editing-2b9300f9df2c
[3] https://github.com/fiduswriter/diffDOM

-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org