> On 14 Oct 2015, at 06:05, Ryosuke Niwa <rniwa@apple.com> wrote: > >> 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. I'd be more nuanced here. Restricting the normal operations of IMEs is indeed hindering user's ability to edit text. But editing the DOM is not inherent to the way IMEs work. While IMEs can work on rich text, they are not a rich text editor. It seems perfectly legitimate to want the ability to place the caret in the middle of <p>日本<b>語</b></p>, press the reverse conversion shortcut, and get the whole 日本語 word thrown back into the IME for editing. But that does not mean the IME needs the ability to make arbitrary modifications to the DOM. If this intent to do a reverse conversion is signaled by an appropriate (series of) events (e.g. select word + composition start), we could still let js be in charge of all DOM modifications: create a piece of (shadow) DOM somewhere, copy the relevant word there, move the selection, and wait for composition end to commit back the result to where it belongs, after possibly altering the markup. That way, IMEs can still be applied to styled text, and even possibly to generate styled text (although I am more skeptical about that being desirable), but js does not lose control over the DOM, and gets a chance to fix up the markup before committing the final content. - Florian
Received on Wednesday, 14 October 2015 01:41:29 UTC