- From: Florian Rivoal <florian@rivoal.net>
- Date: Wed, 14 Oct 2015 16:36:10 +0900
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: Johannes Wilm <johannes@fiduswriter.org>, Koji Ishii <kojiishi@gmail.com>, Piotr Koszuliński <p.koszulinski@cksource.com>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>, kochi@chromium.org
> > On 14 Oct 2015, at 12:30, Ryosuke Niwa <rniwa@apple.com> wrote: > > I think you misunderstood my point. That's precisely what I'm saying here. Great. >> 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. > > This exact approach wouldn't work (for reasons I wouldn't explain since that's not your main point) but some approach like that should work in theory. > >> 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. > > Yeah, Ben and I spent a lot of time discussing about this two years ago, but the key is to come up with the right abstraction layer that supports input methods and spellchecking without compromising the ability for authors to control DOM or restrict what users can do to edit text. So the approach I suggested doesn't work, but do you have one that does? If not, should we make a wiki page of some kind about the various approaches considered so far, and why they don't work, to serve as inspiration to the next person trying to crack the problem? - Florian
Received on Wednesday, 14 October 2015 07:36:43 UTC