Re: Composition, IME, etc.

On Jun 23, 2014, at 8:45 , Robin Berjon <robin@w3.org> wrote:

> I never said that the browser would only provide underlining information. I said it can convey *style*. If it knows that the specific composition being carried out requires bolding, then it could provide the matching CSS declaration. If there is an alien composition method that requires red blinking with a green top border, it could convey that.
> 
> Having said that, having the browser convey style information to the script with the expectation that the script would create the correct Range for the composition in progress and apply that style to it, even though possible, seems like a lot of hoops to jump through that are essentially guaranteed to be exactly the same in every single instance.
> 
> I think we can do better. It's a complicated-sounding solution but the problem is itself complex, and I *think* that it is doable and the best of all options I can think of.
> 
> To restate the problem:
> 
>  We don't want the browser editing the DOM directly because that just creates madness
>  We want to enable any manner of text composition, from a broad array of options, while showing the best UI for the user.
> 
> These two requirements are at odds because rich, powerful composition that is great for the user *has* to rely on the browser, but the logical way for the browser to expose that is to use the DOM.
> 
> The idea to ally both is to use a "shadow text insertion point". Basically, it is a small DOM tree injected as a shadow at the insertion point (with author styles applied to it). The browser can do *anything* it wants in there in order to create a correct editing UI. While composition is ongoing, the script still receives composition events but can safely just ignore them for the vast majority of cases (since you can't generally usefully validate composition in progress anyway). When the composition terminates, the input event contains the *text* content of the shadow DOM, which is reclaimed.
> 
> I guess that the shadow text insertion point would participate in the tree in the same way that a pseudo-element does. (Yes, I realise this basically means "magic".)
> 
> I believe this works well for the insertion of new text; I need to mull it over further to think about editing existing content (notably the case that happens in autocorrect, predictive, and I believe Kotoeri where you place a cursor mid-word and it will take into account what's before it but not after). But I think it's worth giving it some thought; particularly because I don't see how we can solve this problem properly otherwise.
> 
> This has the advantage that it is also a lot simpler to handle for authors.

I think as an application developer Id like this  Id rather avoid having to implement interaction with input methods myself. I also dont think its madness to let the browser and input methods change the content of the single text node that contains the current selection  the madness starts for me when the browser adds or removes DOM nodes. Obviously, there are boundary cases between the two that would need to be carefully handled; for example, if the user starts typing over a selection that spans multiple nodes, this action would have to be split into a deletion action (which Id want to handle myself) followed by a text input action (which the browser can handle).

Norbert

Received on Monday, 14 July 2014 06:23:37 UTC