Re: Way forward and IME behavior speccing

> 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

Received on Tuesday, 13 October 2015 21:06:20 UTC