Intent to Implement and Ship: Basic InputEvent interface

[Chong]

Contact emails

cho...@chromium.org, dtap...@chromium.org

Spec

http://w3c.github.io/editing/input-events.html

Summary

Add basic InputEvent interface and constructor with no additional attributes.

Will modify both the input events sent for input elements as well as the input events dispatched for Content Editable. (change type from Event to InputEvent)

Motivation

This is the first step for implementing InputEvent, which will allow user input to be managed by script and help interactive with IME.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Interoperability Risk

Firefox: Shipped
Edge: Public support
Safari: Public support

Mozilla, Microsoft and Apple are actively engaged in the editing task force and support implementation of the editing specifications, see mailing list.

Compatibility Risk

Compatibility risk is low because

1) FireFox already ships this

2) InputEvent derives from UIEvent which derives from Event; so all the properties of the event are supported that were previously. Just the prototype chain is slightly different with the more sub-classed object being dispatched.

Ongoing technical constraints

None.

OWP launch tracking bug

http://crbug.com/585875

Entry on the feature dashboard

https://www.chromestatus.com/features/5656380006465536

Requesting approval to ship?

Yes.

[Domenic Denicola]

From: blin...@chromium.org [mailto:blin...@chromium.org] On Behalf Of Chong

> Spec
> http://w3c.github.io/editing/input-events.html

Note that this spec doesn't actually define when an input event should be fired, or with what values. That's instead defined by HTML; see e.g.

> Queue a task to fire a simple event that bubbles named input at the input element.

in https://html.spec.whatwg.org/#text-(type=text)-state-and-search-state-(type=search) and elsewhere.

I've filed https://github.com/whatwg/html/issues/682 to get HTML updated to use InputEvent instead of Event for the "input" event, and to figure out what values to use. This shouldn't really impact your intent to implement, but just wanted to keep you aware.

We should also figure out when beforeinput is dispatched (in the precise sense of HTML, not the imprecise sense of the Editing spec's "when the user has attempted to input in a contenteditable element").

[Simon Pieters (zcorpan)]

On Thursday, February 11, 2016 at 8:24:24 PM UTC+1, Chong wrote:

Contact emails

cho...@chromium.org, dtap...@chromium.org

Spec

http://w3c.github.io/editing/input-events.html

Summary

Add basic InputEvent interface and constructor with no additional attributes.

Firefox shipped InputEvent with the isComposing attribute supported from the start. Is there a good reason to ship just the interface with no attributes, rather than shipping the same featureset as Firefox?

[Dave Tapuska]

Our intent is to implement all of the editing values on InputEvent behind a runtime flag as each platform requires specific work individually to bring up (and we wouldn't enable it everywhere until all platforms were done). FireFox only has one of the attributes in the spec. Although we could add this property to the InputEvent today it would never be populated correctly until we did all the work for the InputEvent.

This seemed like a small piece of work to progressively move us in the correct direction. Alternatively we can put the runtime check in for the new properties and send different events to the page (Event vs InputEvent) based on whether the runtime enable flag was set. I'm fine with either approach.

dave.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Simon Pieters]

On Fri, 12 Feb 2016 15:43:05 +0100, Dave Tapuska <dtap...@chromium.org>
wrote:

> Our intent is to implement all of the editing values on InputEvent
> behind a
> runtime flag as each platform requires specific work individually to
> bring
> up (and we wouldn't enable it everywhere until all platforms were done).
> FireFox only has one of the attributes in the spec. Although we could add
> this property to the InputEvent today it would never be populated
> correctly
> until we did all the work for the InputEvent.
>
> This seemed like a small piece of work to progressively move us in the
> correct direction. Alternatively we can put the runtime check in for the
> new properties and send different events to the page (Event vs
> InputEvent)
> based on whether the runtime enable flag was set. I'm fine with either
> approach.

OK. I think the main thing to consider here is that a positive feature
test in JS should mean that the feature is properly supported. For Event
vs. no-attributes InputEvent, my worry is that pages would assume that
isComposing would work if window.InputEvent is defined. Or something more
silly like:

var isChrome = !!window.InputEvent && !('isComposing' in
InputEvent.prototype);

Or the other way around:

var isIsComposingSupported = !!window.InputEvent && navigator.vendor
!= "Google Inc.";

To obvious way to guard against this is to keep the current behavior until
isComposing is properly supported (on some platform), and then ship the
"whole thing" (on that platform).

Please see https://github.com/Modernizr/Modernizr/wiki/Undetectables for
examples where similar things have been issues in the past (e.g. exposing
HTMLMediaElement#preload but not implementing the feature).

--
Simon Pieters
Opera Software

[Philip Jägenstedt]

Which is the first feature from https://w3c.github.io/editing/ that you think you are likely to ship first? Perhaps InputEvent could be grouped with that flag, and if it should turn out to be wrong, it can be moved to another flag?

Based on an earlier discussion I'm concerned about a lack of interest in maintaining existing features like execCommand, and we also have the non-standard events textInput, webkitBeforeTextInserted and webkitEditableContentChanged (measured in Editor::countEvent) that may overlap. Navigating this space without ending up with multiple overlapping and indefinitely-supported APIs will be tricky.

[Chong]

After further discussion it would be a better idea to ship InputEvent with one or all features together.

So recall the intent to ship and wish to change it as an intent to implement, and it will all be behind a runtime flag.