Contact emails
cho...@chromium.org, dtap...@chromium.org
Spec
Link to spec (Blink, Level 1):
https://www.w3.org/TR/2017/WD-input-events-1-20170321/
Webkit is shipping Level 2:
https://www.w3.org/TR/2017/WD-input-events-2-20170321/
Link to a tag review:
https://github.com/w3ctag/spec-reviews/issues/160
Difference between Level 1 and Level 2:
Level 1 - Defines a set of input types that must be cancelable (e.g. Text styling, drag&drop, cut&paste, redo&undo.). Other input types may be non-cancelable.
Level 2 - In addition to Level 1, input types for text insertion and deletion must also be cancelable.
Summary
InputEvent standardized existing ‘input’ events and added ‘beforeinput’ events.
‘beforeinput’ events are fired before user triggered DOM mutations (typing, text styling, paste, redo/undo, etc.), giving JS a chance to understand and prevent default actions.
Similarly, ‘input’ events are fired after DOM mutations.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/Blink-dev/RrnitB0OElc/rirueVekCwAJ
Note that the intent to ship was recalled and changed to intent to implement.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
Proof of concept demo by CKEditor:
http://ckeditor.github.io/ckeditor5-design/poc-typing-beforeinput/
The demo works on Chrome Canary and Safari Technology Preview with experimental feature enabled.
Interoperability and Compatibility Risk
Firefox: Positive (participated in Editing TF)
Edge: Positive (participated in Editing TF)
Safari: Enabled by default as of Safari Technology Preview 18
Web developers: Positive (participated in Editing TF and made demo)
This is a new feature so the interoperability and compatibility risk is low in general.
There could be some potential interop issues as Blink and Webkit is shipping two slightly different spec (Level 1 and Level 2), but they are manageable and shouldn’t affect the overall benefits of shipping InputEvent.
Note:
Web apps based on Level 1 UA will also work on Level 2 UA.
Details about Level 1 and Level 2:
Originally both Blink and Webkit are going to ship Level 2 directly. However based on feedback from Chrome on Android team there are concerns about InputEvent’s approach to Android IME.
The final solution is that Blink will make text insertion and deletion related input types non-cancelable for now (which becomes Level 1 spec) and Webkit will keep their implementation and support all input types (Level 2). More efforts are required for Blink to reach Level 2.
OWP launch tracking bug
Entry on the feature dashboard
https://www.chromestatus.com/features/5656380006465536
First, we should clearly ship this or almost this, I just have a few things.This includes shipping the StaticRange API, for which it seems there is no spec, and Blink's IDL does not match what WebKit has:Is anyone working on a spec for that, and how should we reconcile with WebKit?
Blink's InputEvent.idl also doesn't quite match up with https://www.w3.org/TR/2017/WD-input-events-1-20170321/#interface-InputEvent or https://github.com/WebKit/webkit/blob/1bfaaab3e7bf61dcad32c44a1399914987f9018f/Source/WebCore/dom/InputEvent.idl, can you elaborate on the differences?
As promised elsewhere, I'll also inquire about web-platform-tests for both InputEvent and StaticRange. If they aren't tested, can you file issues to track the eventual full and automated testing of these features as part of web-platform-tests? The bugs could be on Blink or wpt, wherever the problems are.
Thanks for the reply! Please find my responses inlined below.
On Thursday, March 30, 2017 at 12:01:51 PM UTC-4, Philip Jägenstedt wrote:First, we should clearly ship this or almost this, I just have a few things.This includes shipping the StaticRange API, for which it seems there is no spec, and Blink's IDL does not match what WebKit has:Is anyone working on a spec for that, and how should we reconcile with WebKit?
According to https://github.com/w3c/input-events/issues/38#issuecomment-281710402 garykrac@chromium.org will be working on the StaticRange spec.
--
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+unsubscribe@chromium.org.
Regarding StaticRange, it seems weird to me to have non read only attributes (it is static), but that is another story.
Since two implementations exist and both of them are pretty different, I think this needs a bit more than a WICG proposal. A draft specification with multiple vendor participation and consensus would be cool and discussions with WebKit people are, in my opinion, crucial here.Also, since there is no real specification, did Edge and Firefox signal anything about StaticRange? If not, then "Firefox: Positive" and "Edge: Positive" might not be an accurate representation of the entire feature here.
Thanks for the reply! Please find my responses inlined below.
On Thursday, March 30, 2017 at 12:01:51 PM UTC-4, Philip Jägenstedt wrote:First, we should clearly ship this or almost this, I just have a few things.This includes shipping the StaticRange API, for which it seems there is no spec, and Blink's IDL does not match what WebKit has:Is anyone working on a spec for that, and how should we reconcile with WebKit?According to https://github.com/w3c/input-events/issues/38#issuecomment-281710402 gary...@chromium.org will be working on the StaticRange spec.I'm not sure if there is an official spec, but the WICG discussion and proposed IDL can he find here.Blink's implementation was based on the proposed IDL, and I think we should persuade WebKit into matching it.
Blink's InputEvent.idl also doesn't quite match up with https://www.w3.org/TR/2017/WD-input-events-1-20170321/#interface-InputEvent or https://github.com/WebKit/webkit/blob/1bfaaab3e7bf61dcad32c44a1399914987f9018f/Source/WebCore/dom/InputEvent.idl, can you elaborate on the differences?InputEvent IDL was divided into 2 parts:1. UIEvent spec - Input Events, which covers InputEvent.{data, isComposing} and InputEventInit.{data, isComposing}1. InputEvent spec, which covers InputEvent.{inputType, dataTransfer, getTargetRanges()} and InputEventInit.{inputType, dataTransfer, targetRanges}Blink's implementation was based on these two spec and I believe WebKit is missing something.
As promised elsewhere, I'll also inquire about web-platform-tests for both InputEvent and StaticRange. If they aren't tested, can you file issues to track the eventual full and automated testing of these features as part of web-platform-tests? The bugs could be on Blink or wpt, wherever the problems are.We have simple IDL and constructor WPT for InputEvent, however other tests requires input from eventSender/testRunner (keyboard, IME, execCommand) and cannot be written using WPT framework.Here is the tracking bug for rewriting these layout tests into automated manual tests but I haven't given it too much priority. Should we block on shipping on this bug?
For StaticRange I was assuming that we can auto-generate IDL tests when the spec is up, is that correct?
On Fri, Mar 31, 2017 at 1:08 AM Chong <cho...@chromium.org> wrote:
According to https://github.com/w3c/input-events/issues/38#issuecomment-281710402 garykrac...@chromium.org will be working on the StaticRange spec.
I'm not sure if there is an official spec, but the WICG discussion and proposed IDL can he find here.Blink's implementation was based on the proposed IDL, and I think we should persuade WebKit into matching it.
We rarely ship things for which there is no spec, would it make sense to ship InputEvent without the StaticRange bits or would that make it useless?I think we should have a spec with at least IDL to ship, and some agreement about which of Blink and WebKit should change. I don't know the background, but it would seem reasonable to make it immutable and just make the constructor expressive enough to construct all possible StaticRanges?
On Fri, Mar 31, 2017 at 1:08 AM Chong <cho...@chromium.org> wrote:
Thanks for the reply! Please find my responses inlined below.
On Thursday, March 30, 2017 at 12:01:51 PM UTC-4, Philip Jägenstedt wrote:First, we should clearly ship this or almost this, I just have a few things.This includes shipping the StaticRange API, for which it seems there is no spec, and Blink's IDL does not match what WebKit has:Is anyone working on a spec for that, and how should we reconcile with WebKit?
According to https://github.com/w3c/input-events/issues/38#issuecomment-281710402 garykrac...@chromium.org will be working on the StaticRange spec.
I'm not sure if there is an official spec, but the WICG discussion and proposed IDL can he find here.Blink's implementation was based on the proposed IDL, and I think we should persuade WebKit into matching it.
We rarely ship things for which there is no spec, would it make sense to ship InputEvent without the StaticRange bits or would that make it useless?I think we should have a spec with at least IDL to ship, and some agreement about which of Blink and WebKit should change. I don't know the background, but it would seem reasonable to make it immutable and just make the constructor expressive enough to construct all possible StaticRanges?
Blink's InputEvent.idl also doesn't quite match up with https://www.w3.org/TR/2017/WD-input-events-1-20170321/#interface-InputEvent or https://github.com/WebKit/webkit/blob/1bfaaab3e7bf61dcad32c44a1399914987f9018f/Source/WebCore/dom/InputEvent.idl, can you elaborate on the differences?InputEvent IDL was divided into 2 parts:1. UIEvent spec - Input Events, which covers InputEvent.{data, isComposing} and InputEventInit.{data, isComposing}1. InputEvent spec, which covers InputEvent.{inputType, dataTransfer, getTargetRanges()} and InputEventInit.{inputType, dataTransfer, targetRanges}Blink's implementation was based on these two spec and I believe WebKit is missing something.Is the use of /TR/ links here intentional? The data attribute isn't nullable in https://www.w3.org/TR/uievents/#events-inputevents but is in https://w3c.github.io/uievents/#events-inputevents.
Also, new InputEvent('type').data is null in Blink's implementation, but per the spec's IDL it should be "". WebKit is like Blink, so I think the spec is wrong.
Is https://www.w3.org/TR/2017/WD-input-events-1-20170321/#interface-InputEvent really the link to look at, or should it be https://w3c.github.io/input-events/#interface-InputEvent?To bring some clarity to this, can you link to the partial interface definition from InputEvent.idl and file WebKit bugs for the bits they are missing?
As promised elsewhere, I'll also inquire about web-platform-tests for both InputEvent and StaticRange. If they aren't tested, can you file issues to track the eventual full and automated testing of these features as part of web-platform-tests? The bugs could be on Blink or wpt, wherever the problems are.We have simple IDL and constructor WPT for InputEvent, however other tests requires input from eventSender/testRunner (keyboard, IME, execCommand) and cannot be written using WPT framework.Here is the tracking bug for rewriting these layout tests into automated manual tests but I haven't given it too much priority. Should we block on shipping on this bug?No, at this point a lack of web-platform-tests is not blocking, we're just trying to make sure they exist where possible, and to get an idea of common reasons for missing coverage via an umbrella bug. That asks for automated tests as I'm skeptical that manual+automation will scale well, so I asked about automation on the bug.
For StaticRange I was assuming that we can auto-generate IDL tests when the spec is up, is that correct?Yes, an idlharness.js test should be easy. But that doesn't call constructors, methods, know what default values to expect for attributes or know what should happen when you try to set attributes. In other words, it's very surface level and additional tests are needed.
On Monday, April 3, 2017 at 2:06:15 AM UTC-4, Philip Jägenstedt wrote:
On Fri, Mar 31, 2017 at 1:08 AM Chong <cho...@chromium.org> wrote:
Thanks for the reply! Please find my responses inlined below.
On Thursday, March 30, 2017 at 12:01:51 PM UTC-4, Philip Jägenstedt wrote:First, we should clearly ship this or almost this, I just have a few things.This includes shipping the StaticRange API, for which it seems there is no spec, and Blink's IDL does not match what WebKit has:Is anyone working on a spec for that, and how should we reconcile with WebKit?
According to https://github.com/w3c/input-events/issues/38#issuecomment-281710402 gary...@chromium.org will be working on the StaticRange spec.
I'm not sure if there is an official spec, but the WICG discussion and proposed IDL can he find here.Blink's implementation was based on the proposed IDL, and I think we should persuade WebKit into matching it.
We rarely ship things for which there is no spec, would it make sense to ship InputEvent without the StaticRange bits or would that make it useless?I think we should have a spec with at least IDL to ship, and some agreement about which of Blink and WebKit should change. I don't know the background, but it would seem reasonable to make it immutable and just make the constructor expressive enough to construct all possible StaticRanges?
Sorry for the confusion, please see garykac@'s comments about StaticRange spec: https://garykac.github.io/staticrange/
Blink's InputEvent.idl also doesn't quite match up with https://www.w3.org/TR/2017/WD-input-events-1-20170321/#interface-InputEvent or https://github.com/WebKit/webkit/blob/1bfaaab3e7bf61dcad32c44a1399914987f9018f/Source/WebCore/dom/InputEvent.idl, can you elaborate on the differences?InputEvent IDL was divided into 2 parts:1. UIEvent spec - Input Events, which covers InputEvent.{data, isComposing} and InputEventInit.{data, isComposing}1. InputEvent spec, which covers InputEvent.{inputType, dataTransfer, getTargetRanges()} and InputEventInit.{inputType, dataTransfer, targetRanges}Blink's implementation was based on these two spec and I believe WebKit is missing something.Is the use of /TR/ links here intentional? The data attribute isn't nullable in https://www.w3.org/TR/uievents/#events-inputevents but is in https://w3c.github.io/uievents/#events-inputevents.Sorry the link should be https://w3c.github.io/uievents/#events-inputevents and the data attribute should be nullable.Also, new InputEvent('type').data is null in Blink's implementation, but per the spec's IDL it should be "". WebKit is like Blink, so I think the spec is wrong.Yes, it should be a spec issue. Thanks for filing the bug!Is https://www.w3.org/TR/2017/WD-input-events-1-20170321/#interface-InputEvent really the link to look at, or should it be https://w3c.github.io/input-events/#interface-InputEvent?To bring some clarity to this, can you link to the partial interface definition from InputEvent.idl and file WebKit bugs for the bits they are missing?We should be looking at https://www.w3.org/TR/2017/WD-input-events-1-20170321/#interface-InputEvent as Blink is implementing Level 1 spec.
On Apr 4, 2017, at 9:17 AM, Ryosuke Niwa <rn...@apple.com> wrote:The person who knows about StaticRange behavior in WebKit best is Wenson.
- R. NiwaOn Tue, Apr 4, 2017 at 4:25 AM Chong <cho...@chromium.org> wrote:
On Monday, April 3, 2017 at 2:06:15 AM UTC-4, Philip Jägenstedt wrote:On Fri, Mar 31, 2017 at 1:08 AM Chong <cho...@chromium.org> wrote:Thanks for the reply! Please find my responses inlined below.
On Thursday, March 30, 2017 at 12:01:51 PM UTC-4, Philip Jägenstedt wrote:First, we should clearly ship this or almost this, I just have a few things.This includes shipping the StaticRange API, for which it seems there is no spec, and Blink's IDL does not match what WebKit has:Is anyone working on a spec for that, and how should we reconcile with WebKit?According to https://github.com/w3c/input-events/issues/38#issuecomment-281710402 gary...@chromium.org will be working on the StaticRange spec.I'm not sure if there is an official spec, but the WICG discussion and proposed IDL can he find here.Blink's implementation was based on the proposed IDL, and I think we should persuade WebKit into matching it.We rarely ship things for which there is no spec, would it make sense to ship InputEvent without the StaticRange bits or would that make it useless?I think we should have a spec with at least IDL to ship, and some agreement about which of Blink and WebKit should change. I don't know the background, but it would seem reasonable to make it immutable and just make the constructor expressive enough to construct all possible StaticRanges?Sorry for the confusion, please see garykac@'s comments about StaticRange spec: https://garykac.github.io/staticrange/Thanks, that was fast! To mitigate the interop risk, I think what matters most here is some buy-in from WebKit (+Ryosuke Niwa) about making StaticRange mutable.Are any of the StaticRange instances created by the UA ever mutated by the UA, or is the mutability simply about making StaticRange more useful for other purposes?
Are any of the StaticRange instances created by the UA ever mutated by the UA, or is the mutability simply about making StaticRange more useful for other purposes?
> On Apr 4, 2017, at 1:33 PM, Gary Kačmarčík (Кошмарчик) <gar...@google.com> wrote:
>
> Well, it's static WRT the DOM mutations (as a contrast to Range). It isn't intended to mean that the attributes are all static.
Why not? StaticNodeList is immutable. You can’t remove or insert a new node.
I’d expect the primary data held by an interface named StaticRange to be immutable.
> We always have the option of making it mutable later if needed.
I don’t think we should make StaticRange mutable ever. I don’t even understand where this discussion about making it mutable comes from.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Thanks for getting StaticRange in order! Gary, can you see about moving it to w3c.github.io?For Level 2, is it just that an exact ETA isn't possible, or is it possible that this will remain unresolved 2 years from now? If it's anything more than a few months, then my question stands about how the spec for Level 1 will be maintained. Is there a branch for Level 1 so that one could see how big the differences to Level 2 actually are?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Can you arrange for v1 to be auto-published somewhere so that our links always lead to something that's up-to-date and represents what we should implement? Also, can you file a bug for Level 2 support?
I remain concerned that this will become a long-standing difference between Blink and WebKit, but see nothing more that can be done to mitigate it. LGTM3.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
On Monday, April 24, 2017 at 5:11:20 AM UTC-4, Philip Jägenstedt wrote:Can you arrange for v1 to be auto-published somewhere so that our links always lead to something that's up-to-date and represents what we should implement? Also, can you file a bug for Level 2 support?Sure! Here is the spec bug for auto-publishing Level 1: https://github.com/w3c/input-events/issues/62And Blink bug for Level 2 support: https://crbug.com/714791