Going back to contenteditable=events

Hi all,

== Background ==

I've been thinking about various problems about IME, and I think we should go back to contenteditable=events because letting Web browsers make any DOM mutations is a slippery slope.

We went with contenteditable=typing because the composition text had to be rendered differently than ordinary text and we couldn't expose every IME state (e.g. candidate states).  But there is an alternative approach that doesn't invoke DOM mutations.

We (Apple) have also found another issue with the current design. We need to remember when autocorrections are reverted by the user (via undo). In order for features like these to work, we need to attach meta data on text the user had typed. Furthermore, single text node model of IME doesn't work for more advanced text editors; e.g. one with a custom justification algorithm which needs to replace each character in a separate div.

== Proposal ==

1. We make all IME actions/commands simply requests from Web browsers.  JS will have full control over what it does with those requests.
2. Web browsers automatically stylizes and remembers meta data for the typed text based on caret (collapsed selection) location and innerText of the closest editing host (root editable node).

(2) is the key. Instead of browser taking the control of what's happening in IME, etc..., we'll get the state out of the Web apps. We would treat everything in the current contenteditable=events (except contenteditable=false contents) as the pre-existing text + user edited text.  This will allow browsers to map the current content with what the user had typed, etc... This should work 99% of the time when the apps are respecting browser/user issued IME requests.

- R. Niwa

Received on Wednesday, 21 October 2015 05:43:31 UTC