W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2015

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

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Thu, 2 Jul 2015 23:20:35 +0000
To: Arthur Barstow <art.barstow@gmail.com>, Ryosuke Niwa <rniwa@apple.com>
CC: public-webapps <public-webapps@w3.org>
Message-ID: <BLUPR03MB389E9D4544C9725A8C52B8BF8970@BLUPR03MB389.namprd03.prod.outlook.com>
Arrg. It's far-less used than I thought.

It turns out that it _was_ used in production last year, but then it was removed from production when a UI change interfered and the bug to fix it is still open :(

So, my guess is that as of today, we have infinitesimal-small usage of this API in IE.

-----Original Message-----
From: Travis Leithead 
Sent: Thursday, June 18, 2015 11:49 AM
To: 'Arthur Barstow'; Ryosuke Niwa
Cc: public-webapps
Subject: RE: [ime-api] [blink-dev] Removing IME API code from Blink

I've posted the notice on the editor's draft as suggested below. If there is help to continue to advance the direction of this spec, I'd love to see it continue to evolve.

Note, that our Chinese Bing home page (http://www.bing.com/?mkt=zh-CN) employs the use of a version of this API (prefixed, in IE11 & Edge), but the API only lights up when you use built-in Microsoft IMEs (not 3rd party IMEs at the moment :( ).

-----Original Message-----
From: Arthur Barstow [mailto:art.barstow@gmail.com] 
Sent: Thursday, June 11, 2015 3:42 AM
To: Travis Leithead; Ryosuke Niwa
Cc: public-webapps
Subject: Re: [ime-api] [blink-dev] Removing IME API code from Blink

On 5/28/15 2:04 PM, Travis Leithead wrote:
> 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 :)

Given this, it seems like the SoTD section should include some type of 
large-ish warning/note that include text along the lines of `no one is 
actively working on this spec nor its implementation` + `help wanted`. 
Also, if the spec's [Issues] and [Bugs]  haven't properly captured the 
ClientRect exposure issue, perhaps one should be created (and/or the 
spec updated to reflect this).

On the other hand, if you propose to formally stop work on the spec "as 
it is" now, then it would be appropriate to have a CfC to publish a WG 
Note (and if/when there is a firm commitment to do some type of followup 
work, a new spec can be created).


-Thanks, ArtB

[Issues] https://github.com/w3c/ime-api/issues

> -----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, 2 July 2015 23:21:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:57 UTC