That sounds good to me (working the UI challenges for IME together with grammar/spell checking). Is this a direction the current IME spec could take--possibly with a big refactor to consider dropping the ClientRect exposure--or would it be better to publish as Note the current approach and start a new spec?
Perhaps it doesn't really matter as the above is a process question, and what is really needed is someone to start suggesting some concrete proposals here--I've been pretty much ignoring this spec for the past year, and I don't see that changing in the near future. It's still something I'd like to see moved forward, I just don't believe I have the time to move it substantially forward at the present moment :) -----Original Message----- From: Ryosuke Niwa [mailto:rn...@apple.com] Sent: Wednesday, May 27, 2015 7:00 PM To: Travis Leithead Cc: Arthur Barstow; public-webapps Subject: Re: [ime-api] [blink-dev] Removing IME API code from Blink > On May 27, 2015, at 11:46 AM, Travis Leithead <travis.leith...@microsoft.com> > wrote: > > I believed the use-cases for avoiding UI clashes between site-driven > auto-complete lists and IME auto-complete boxes is still a valid use case, > and I think the spec is still valid to try to push to recommendation. > However, I'd also like to follow up on usage of the ms- prefixed API so that > I can get an idea of what its real usage is. I agree avoiding UI clashes between auto-completions of IME and web page is a great use case but I'm not convinced that exposing ClientRect for IME is the right API as many Web developers aren't even aware of UI challenges IME imposes. For example, a similar UI challenge emerges when dealing with auto-corrections in grammar/spell checking features as well. It would be ideal if IME and spell/grammar corrections are handled in a similar manner so that Web apps supporting either feature will "just work" with both features. - R. Niwa
