Announcement: implementation intent for IME API

[Kenji Baheux]

Hi,

I hope I am doing this right :)

This is to announce our intent to start working on the implementation of the IME API.

This API provides web applications with scripted access to an IME (input-method editor) associated with a hosting user agent.

Our OWP launch bug was filed at crbug.com/226938 (Eng. owner: ko...@chromium.org; aiming for a behind the flag implementation in Chrome M29)

This was marked as an F1 P2 at chromestatus.com but it feels more like an F2 P2 given that we are not adding a large numbers of methods or properties. That being said, correct me if I am wrong in this assessment.

Documented support:

• Positive support from Microsoft
  
• http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/1059.html
• http://www.w3.org/2012/10/30-webapps-minutes.html#item04"
• Mixed feelings from Mozilla and Apple
  
• http://www.w3.org/2012/10/30-webapps-minutes.html#item04"
  
• Although, the negative comments were solely focused on the JS IME bits in the draft (now removed from the spec).

Comments welcomed.

[Max Heinritz]

Thanks for the notice, Kenji. I hope I'm doing this right too :)

I created an APAC-friendly API review meeting next week (3:30 PST on Tuesday, 4/9) and given you guys a slot. It's pretty early TOK time.

If folks don't think a review is needed, please chime in on this thread. Otherwise, expect to cover the following in the meeting:

1. Rationale and use-cases

2. Current state and alternatives to native web support

3. If launched behind flag already, discuss feedback received

4. Compatibility risk

5. What's left to do?

6. Desired path to launch.  Any specific milestone target?  Any external time sensitivity? Etc.

This doc lists upcoming API topics and the format of the meeting.

Max

[Adam Barth]

I'd be inclined to err on the side of discussing things in an API review at the beginning.  As we get more experience, we should get a better sense for when we can proceed without a face-to-face review.

Adam

[Alex Komoroske]

100% agreed with Adam. Over time we can reduce the need for face to face stuff as we get a feel for how this works, but at the beginning it's good to err on the side of caution.

[Eric Seidel]

I am excited about this feature!  I suspect the spec will evolve further as we implement this and try to use it. :)

Based on it's acceptance by the W3C and Mozilla's support this would qualify under Guideline #4.

LGTM to implement (behind a runtime flag).  Please bring this back to feature review when we believe this is ready to ship to stable.

Apologies for the delay!

[Kenji Baheux]

Thanks!

2013/04/16 6:37 "Eric Seidel" <ese...@chromium.org>:

[Ojan Vafai]

I think this is a great API to add, but I had a few concerns/questions about the details. Happy to discuss it here or on public-webapps. This does not need to block implementing behind a flag.

• I think it would be great to make this API a bit more general about editing and not just IMEs, i.e. enabling the input context also enables beforeInput/input events to fire. It should get you all the editing-related events without the actual editing behavior. Then this API can be used more broadly for other editing use-cases as well.
  
• It's weird to have the enabled property be writable when there's an open method and it sounds like sometimes enabling can fail. What are the circumstances where it can fail? How about s/open/enable?
  
• Can "caret" ever be a non-collapsed range? If not, then we should expose a new Position object that is just a Node and an offset?
  
• Why is "text" a Node? Why not have CompositionDictionary have the same accessors as CompositionEvents (i.e. data and locale as DOMStrings)? What makes it so that the node in question only contains the composition text and not other text?
  
• Why is there setCaretRectangle and setExclusionRectangle?
  
• "When a Web application draws composition text, it must call preventDefault() in compositionupdate handler so that the user agent will not draw the text." This is only true in an editable region, right? I'm not really sure this text is useful or belongs in this spec.
  
• Do we need a method getInputContext? Can this just be an inputContext property?

Here's a thought for a completely different API. What if HTMLElement just had an inputEnabled property which caused the element to get editing events (composition*, beforeInput, input) and then the composition events themselves had setExclusionRectangle, setCaretRectangle and confirmComposition? What's the benefit of being able to get at information about the composition outside of composition events?

Again, happy to bring this up on public-webapps, but I thought I'd mention it here first to get your initial thoughts and maybe to explain some of the bits about the API that confused me.

[Takayoshi Kochi]

Hi Ojan,

Thanks for the comments and interest.

Let's continue discussion on public-webapps.

To answer the first bullet, it is a high-level question.  It would be great if the API covers more comprehensive,

but if we incorporate any input system, the API may get bloated, unnecessarily complex or involve endless disputes.

We think we'd like to focus on solving issues related to IME using languages.

Other bullet points are quite valid.  I also felt similar, but as I took over the spec from the previous

author and without open discussion, I hesitated to make my arbitrary changes - so the comments are

very welcome!

--
Takayoshi Kochi

[Mounir Lamouri]

On 15/04/13 17:37, Eric Seidel wrote:
> I am excited about this feature! I suspect the spec will evolve further
> as we implement this and try to use it. :)
>
> Based on it's acceptance by the W3C and Mozilla's support this would
> qualify under Guideline #4.

Even if we agree that this API is covering interesting use cases, we
(Mozilla) have currently no plans to implement this.

However, we are working on an API that allows a web application to be an
IME in the context of Firefox OS [1]. I believe that Chrome has the same
kind of functionality [2]. We would be very interested in working
together on that.

[1] https://wiki.mozilla.org/WebAPI/KeboardIME (WIP, not shipped yet)
[2] http://developer.chrome.com/dev/extensions/input.ime.html

Cheers,
--
Mounir