22094 2013-05-20 04:10:43 +0000 Add 'target' in InputMethodContext 2013-07-04 07:40:44 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - IME API unspecified All All RESOLVED FIXED P2 normal --- 1 kochi kochi adrianba masayuki mike mounir public-webapps travil public-webapps-bugzilla oldest_to_newest 87892 0 kochi 2013-05-20 04:10:43 +0000 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. 87919 1 masayuki 2013-05-20 11:15:19 +0000 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. 87933 2 travil 2013-05-20 19:17:48 +0000 (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. 87935 3 masayuki 2013-05-20 19:53:50 +0000 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? 88309 4 travil 2013-05-28 22:10:54 +0000 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. 90340 5 kochi 2013-07-04 07:40:44 +0000 I'll add this to the next working draft update.