Re: [editing-explainer] How does cE=typing support IME text replacement? (#34)

> Personally I'm not thrilled about using custom elements as a requirement to using cE=typing. Custom Elements is a new technology, and judging by the number of emails that come through my inbox it sounds like there is a lot of work still going on.

Custom elements and shadow DOM are two different animals, and Shadow DOM is much more stable. Chrome has been using this "shadow DOM"  to implement <input> internally, but that's not defined in the spec. It's an implementation details.

> What are the issues that are causing us to want to reinvent the way we handle IMEs?

It's not really a reinvent. Let me re-phrase the question: should IME interim states (un-commited strings) visible to DOM or not? Existing implementations vary: Windows does not expose them unless apps opt-in, I don't know how OS X/Linux API does for this. Browsers used to expose by default, though I'm not sure if this was spec'ed and interoperable. Probably not.

By exposing, we'll need to define replace/delete behavior, since IME makes a lots of inserts/deletes/replaces during the interim states.

If we change it not to expose, all what IME does is inserting text on commits, which aligns well with cE=typing, and we can resolve this issue. Since what we're trying to do is to minimize browsers doing special operations to the DOM, I think not exposing aligns to our overall direction.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing-explainer/issues/34#issuecomment-70509989