RE: [ime-api] [blink-dev] Removing IME API code from Blink

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:rniwa@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.leithead@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

Received on Thursday, 28 May 2015 18:04:56 UTC