This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23422 - Adding a method to deliver editing-related events to a DOM element
Summary: Adding a method to deliver editing-related events to a DOM element
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - IME API (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Takayoshi Kochi
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-02 07:45 UTC by Takayoshi Kochi
Modified: 2013-10-10 08:11 UTC (History)
7 users (show)

See Also:

Attachments

Description Takayoshi Kochi 2013-10-02 07:45:17 UTC 
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).
Comment 1 Ojan Vafai 2013-10-02 18:22:48 UTC 
What are the cases where the request would fail?
Comment 2 Takayoshi Kochi 2013-10-03 03:56:27 UTC 
(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.
Comment 3 Ojan Vafai 2013-10-04 01:34:21 UTC 
(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?
Comment 4 Takayoshi Kochi 2013-10-04 08:05:52 UTC 
(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?
Comment 5 Ojan Vafai 2013-10-04 17:15:51 UTC 
Sounds good to me.
Comment 6 Takayoshi Kochi 2013-10-10 08:11:58 UTC 
Added enable/disableEditingEvents() at
https://dvcs.w3.org/hg/ime-api/rev/10a3d6ec9336