23422 2013-10-02 07:45:17 +0000 Adding a method to deliver editing-related events to a DOM element 2013-10-10 08:11:58 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - IME API unspecified All All RESOLVED FIXED P2 normal --- 1 kochi kochi adrianba masayuki mike ojan public-webapps travil yoichio public-webapps-bugzilla oldest_to_newest 94158 0 kochi 2013-10-02 07:45:17 +0000 In the current IME API WD (http://www.w3.org/TR/2013/WD-ime-api-20130815/ , section 8.2) using HTML5 'inputmode' attribute to specify that an element wants editing related events (such as input, beforeinput, composition events) but it sounded somewhat weird way to tell the hosting user agent in this way. Instead, we propose to add a method to InputMethodContext, as bool requestEventDelivery(); to tell the target element wanting editing events delivered when it gets focus, if the target element is a non-editable one (i.e. not <input>, <textarea>, or contenteditable). By using this a developer can turn a DOM element to behave like an editing element, to construct a DOM-based text editor. If the user agent cannot fulfill the request, it can return false to indicate that the request is failed. We also might want to introduce another interface to undo the request: void refuseEventDelivery(); which should always succeed (as not delivering events is the default). 94190 1 ojan 2013-10-02 18:22:48 +0000 What are the cases where the request would fail? 94220 2 kochi 2013-10-03 03:56:27 +0000 (In reply to Ojan Vafai from comment #1) > What are the cases where the request would fail? For example, an element embedding a plugin (notably Flash), which user agents handle specially, may not be eligible for forwarding the input events, as far as I can imagine, but such a case may be ignorable. 94287 3 ojan 2013-10-04 01:34:21 +0000 (In reply to Takayoshi Kochi from comment #2) > (In reply to Ojan Vafai from comment #1) > > What are the cases where the request would fail? > > For example, an element embedding a plugin (notably Flash), which > user agents handle specially, may not be eligible for forwarding the > input events, as far as I can imagine, but such a case may be ignorable. The same argument applies to addEventListener('click') on such an element, right? It seems better to me to not make this a "request" style API. How about enableEditingEvents? 94301 4 kochi 2013-10-04 08:05:52 +0000 (In reply to Ojan Vafai from comment #3) > > > What are the cases where the request would fail? > > > > For example, an element embedding a plugin (notably Flash), which > > user agents handle specially, may not be eligible for forwarding the > > input events, as far as I can imagine, but such a case may be ignorable. > > The same argument applies to addEventListener('click') on such an element, > right? It seems better to me to not make this a "request" style API. How > about enableEditingEvents? Thanks for the suggestion, it sounds good to me. Then do * enableEditingEvents() * disableEditingEvents() sound good to you? 94313 5 ojan 2013-10-04 17:15:51 +0000 Sounds good to me. 94548 6 kochi 2013-10-10 08:11:58 +0000 Added enable/disableEditingEvents() at https://dvcs.w3.org/hg/ime-api/rev/10a3d6ec9336