This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As described in Microsoft's IME API proposal https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html add 'target' property which is a back pointer to the associated input element.
As I said in bug 22093 comment 2, I believe that the target should be the editing host element of the element. I.e., if the InputMethodContext instance is created for <input> or <textarea>, then, it must refer the element itself. Otherwise, i.e., created for an element in HTML editor, it must refer the editing host because editing host is the usual event target of key and composition DOM events.
(In reply to comment #1) > As I said in bug 22093 comment 2, I believe that the target should be the > editing host element of the element. I.e., if the InputMethodContext > instance is created for <input> or <textarea>, then, it must refer the > element itself. Otherwise, i.e., created for an element in HTML editor, it > must refer the editing host because editing host is the usual event target > of key and composition DOM events. Yes, this is the intent. We expect that the InputMethodContext for a contenteditable region should be the "host element" of the editing context, not any of the dynamic content inside. This same "host element" also forms the root for index parameters like the offsets of the composition text.
Then, https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html#widl-HTMLElement-getInputContext-InputMethodContext > Returns an InputMethodContext interface associated with *this* element, regardless of whether it's editable or not. "this" sounds strange for me. Additionally, in following case, what happens? <body> <div id="parent"> <div id="child"> <em id="em">foo bar</em>. </div> </div> </body> var contextOfEm = document.getElementById("em").getInputContext(); var contentOfParent = document.getElementById("parent").getInputContext(); // Are the both result of .target are null? document.getElementById("child").setAttribute("contenteditable", "true"); // Is the result of contentOfEm.target the <div id="child"> element, but contentOfParent.target is null? document.body.setAttribute("contenteditable", "true"); // Are the both result of .target the <body> element? If so, each InputMethodContext instance needs to store the element which created the instance?
We should change Returns an InputMethodContext interface associated with this element, regardless of whether it's editable or not. To Returns an InputMethodContext interface associated with this element, regardless of whether it's editable or not. If this element is a child element of an editable region, then returns an InputMethodContext interface associated with the containing element of the editable region. Turning something on the page into editable shouldn’t change the existing InputMethodContext instances of its child or parent elements, otherwise it’ll be too complicated to dynamically switch all the existing contexts. The developer should get those contexts again if he changes something into editable.
I'll add this to the next working draft update.