Intent to Ship: InputEvent

[Chong]

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

crbug.com/585875

Entry on the feature dashboard

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

[Dimitri Glazkov]

LGTM1

[Philip Jägenstedt]

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:

https://github.com/WebKit/webkit/blob/1bfaaab3e7bf61dcad32c44a1399914987f9018f/Source/WebCore/dom/StaticRange.idl

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.

[Chong]

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:

https://github.com/WebKit/webkit/blob/1bfaaab3e7bf61dcad32c44a1399914987f9018f/Source/WebCore/dom/StaticRange.idl

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?

[PhistucK]

Thank you, Philip, as always, for pointing out the hidden issues. I was too naive and just thought this was a great addition. :(

Regarding the interoperability risk, it is definitely not low, as WebKit and Blink will be the only supporting engines (which equals a mobile lock-in). Plus, the implementations differ.

The fact that others are positive about it is encouraging, but can you file bugs for adding support in Edge and Firefox or see whether they intend to ship (and which level?) or to develop in the near future?

Also, have you used the layout tests of WebKit to ensure the two implementations are interoperable (modulo level 2 features, obviously)?

Those events are very useful, but unless they are interoperable, they can cause a lot of pain (like the current editing situation). I think it is very important to verify interoperability between the two implementations (and obviously, encourage other engines to ship as well).

Also - and I understand this is hard - I think this is a good opportunity to try and invest in a Web Platform Tests API or infrastructure that will let the browser emulate this somehow, even if it must run in some testing mode or whatever. This area is in great need of interoperability.

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.

Unfortunately, as it currently stands, I do not think this should be shipped. It is not interoperable enough.

☆PhistucK

On Thu, Mar 30, 2017 at 9:08 PM, 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:

https://github.com/WebKit/webkit/blob/1bfaaab3e7bf61dcad32c44a1399914987f9018f/Source/WebCore/dom/StaticRange.idl

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.

[Gary Kačmarčík (Кошмарчик)]

On Thu, Mar 30, 2017 at 3:26 PM, PhistucK <phis...@gmail.com> wrote:

Regarding StaticRange, it seems weird to me to have non read only attributes (it is static), but that is another story.

It's "static" in the sense that it does not update when the DOM is mutated. We discussed many different names and this was the best one that we (Chrome, Firefox, Safari, Edge) could agree on.

 

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.

StaticRange spec was discussed at the last TPAC (Chrome, Firefox, Safari, Edge): https://www.w3.org/2016/09/22-webapps-minutes.html#item08

More recently, it was discussed (Chrome, Firefox, Safari, Edge, et al.) in this bug: https://github.com/w3c/input-events/issues/38

And final confirmation of agreement was from the Editing TG meeting on 14 March:

https://lists.w3.org/Archives/Public/public-editing-tf/2017Mar/0004.html

The current draft of the specification is at: https://garykac.github.io/staticrange/

Note that the spec was on hold for a while while we decided between dictionary and interface (since a dictionary doesn't need a spec). With the recent agreement on an interface, we will be moving forward with the specification.

[Gary Kačmarčík (Кошмарчик)]

-gary...@chromium.org

+gar...@chromium.org

[Philip Jägenstedt]

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:

https://github.com/WebKit/webkit/blob/1bfaaab3e7bf61dcad32c44a1399914987f9018f/Source/WebCore/dom/StaticRange.idl

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?

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.

[Gary Kačmarčík (Кошмарчик)]

On Sun, Apr 2, 2017 at 11:05 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

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?

https://garykac.github.io/staticrange/

[Chong]

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:

https://github.com/WebKit/webkit/blob/1bfaaab3e7bf61dcad32c44a1399914987f9018f/Source/WebCore/dom/StaticRange.idl

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?

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.

I've uploaded CL to update spec links in InputEvent(Init).idl and filed WebKit bugs:

  * https://bugs.webkit.org/show_bug.cgi?id=170414

  * https://bugs.webkit.org/show_bug.cgi?id=170416

 

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.

 

I've replied in 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.

Here are the CLs for updating StaticRange.idl spec link (https://codereview.chromium.org/2793093002/) and StaticRange web-platform-tests (https://codereview.chromium.org/2791373002/).

[Philip Jägenstedt]

On 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:

https://github.com/WebKit/webkit/blob/1bfaaab3e7bf61dcad32c44a1399914987f9018f/Source/WebCore/dom/StaticRange.idl

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?

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.

With my API owners hat off, levels of a spec make me nervous, as usually level N+1 repeats or redefines some of level N instead of being a completely independent spec, in which case it probably wouldn't be called a level.

In this case, will https://www.w3.org/TR/2017/WD-input-events-1-20170321/#interface-InputEvent continue to be maintained as issues are found and fixed in https://w3c.github.io/input-events/? If not, I worry that one year from now, there will be no combination of specs that describes what is shipping in Chrome. How much to worry depends on when level 2 will be implemented in Blink, is there an ETA for that?

I've uploaded CL to update spec links in InputEvent(Init).idl and filed WebKit bugs:

  * https://bugs.webkit.org/show_bug.cgi?id=170414

  * https://bugs.webkit.org/show_bug.cgi?id=170416

Thanks for filing those bugs!

[Ryosuke Niwa]

The person who knows about StaticRange behavior in WebKit best is Wenson.

- R. Niwa

[Wenson Hsieh]

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. Niwa

On Apr 4, 2017, at 03:58, Philip Jägenstedt <foo...@chromium.org> wrote:

On 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:

https://github.com/WebKit/webkit/blob/1bfaaab3e7bf61dcad32c44a1399914987f9018f/Source/WebCore/dom/StaticRange.idl

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?

Currently, WebKit’s StaticRange is immutable — see https://github.com/WebKit/webkit/blob/1bfaaab3e7bf61dcad32c44a1399914987f9018f/Source/WebCore/dom/StaticRange.idl for reference. The StaticRanges generated by WebKit (currently, this is only for the purpose of populating target ranges in an InputEvent) are never mutated after creation. However, I can understand why StaticRanges might need to be mutable if we want to use them for other purposes, and I’m not opposed to making these attributes mutable and adding StaticRange.setStart and StaticRange.setEnd. Ryosuke, does this seem reasonable to you?

[Gary Kačmarčík (Кошмарчик)]

On Tue, Apr 4, 2017 at 3:58 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

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?

The mutability is primarily about making StaticRange more generally useful.

In input events, StaticRanges are just to pass the range back to JavaScript. They aren't expected to be used by the UA after they are created.

[Ryosuke Niwa]

I don't quite understand what the point of making StaticRange mutable. It says Static in its name, why make it mutable? Scripts can just create a new StaticRange with new offsets or nodes instead.

- R. Niwa

[Gary Kačmarčík (Кошмарчик)]

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.

The current Input event use case doesn't need it to be mutable, so if this is an issue, we can certainly make StaticRange immutable now.

We always have the option of making it mutable later if needed.

[Ryosuke Niwa]

> On Apr 4, 2017, at 1:33 PM, Gary Kačmarčík (Кошмарчик) <gar...@google.com> wrote:
>
> On Tue, Apr 4, 2017 at 9:46 AM, Ryosuke Niwa <rn...@apple.com> wrote:
>>
>> On Apr 4, 2017, at 09:40, Gary Kačmarčík (Кошмарчик) <gar...@google.com> wrote:
>>
>>> On Tue, Apr 4, 2017 at 3:58 AM, Philip Jägenstedt <foo...@chromium.org> wrote:
>>>
>>> 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?
>>>
>>> The mutability is primarily about making StaticRange more generally useful.
>>>
>>> In input events, StaticRanges are just to pass the range back to JavaScript. They aren't expected to be used by the UA after they are created.
>>
>> I don't quite understand what the point of making StaticRange mutable. It says Static in its name, why make it mutable? Scripts can just create a new StaticRange with new offsets or nodes instead.
>
> 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.

> The current Input event use case doesn't need it to be mutable, so if this is an issue, we can certainly make StaticRange immutable now.
>
> 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.

- R. Niwa

[Gary Kačmarčík (Кошмарчик)]

On Tue, Apr 4, 2017 at 1:39 PM, Ryosuke Niwa <rn...@apple.com> wrote:

> 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.

This is actually key.  Your expectation here is perfectly reasonable, and we do need to be consistent with our naming of objects.

Given that people expect StaticXxx to be an attribute-immutable Xxx object, then I agree StaticRange needs to be attribute-immutable (even though our primary motivation for creating StaticRange is so the range is static with respect to DOM mutations).

> 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.

The concern (perhaps unfounded) is that it would be nice if our DOM-immutable range object is more generally useful than just this particular case. We anticipate that this object will be used for most/all new APIs where a Range would have been used in the past, and Range is mutable (both in the DOM-selection and attribute sense).

However this is something that we can address if/when we ever need an attribute-mutable DOM-immutable range object. And StaticRange (as noted above) is not a great name for that sort of object in any case.

Given that, I'll update the spec to make StaticRange immutable (readonly attributes).

[Ryosuke Niwa]

> On Apr 4, 2017, at 2:31 PM, Gary Kačmarčík (Кошмарчик) <gar...@google.com> wrote:
>
> On Tue, Apr 4, 2017 at 1:39 PM, Ryosuke Niwa <rn...@apple.com> wrote:
>>
>> > 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.
>
> This is actually key. Your expectation here is perfectly reasonable, and we do need to be consistent with our naming of objects.
>
> Given that people expect StaticXxx to be an attribute-immutable Xxx object, then I agree StaticRange needs to be attribute-immutable (even though our primary motivation for creating StaticRange is so the range is static with respect to DOM mutations).
>>
>> > 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.
>
> The concern (perhaps unfounded) is that it would be nice if our DOM-immutable range object is more generally useful than just this particular case. We anticipate that this object will be used for most/all new APIs where a Range would have been used in the past, and Range is mutable (both in the DOM-selection and attribute sense).

Why would that warrant StaticRange’s attributes to be mutable? For example, methods to compute the caret rect doesn’t modify the range at all. Methods to extend range, etc… could simply return a new StaticRange instead of modifying it.

> However this is something that we can address if/when we ever need an attribute-mutable DOM-immutable range object. And StaticRange (as noted above) is not a great name for that sort of object in any case.

I still don’t understand in what concrete use cases we would like StaticRange’s attributes to be mutable.

- R. Niwa

[Philip Jägenstedt]

https://garykac.github.io/staticrange/#interface-staticrange has been updated such that it now matches WebKit exactly except for the ordering of the attributes, which is very rarely a problem. Maybe there should be a constructor, but if that gets bogged down I don't think it should block shipping.

Chong, when you believe everything with StaticRange is in order, can you ping this thread?

There is still the interop risk related to Level 1 vs. Level 2, and I'm curious about my earlier questions about an ETA to resolve.

[Chris Harrelson]

LGTM2 to ship level 1. It sounds like level 2 requires more work to get an agreed-upon solution.

[Chong]

Blink's StaticRange should be matching spec and WebKit now (except the ordering, see https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/StaticRange.idl).

Regarding Level 1 vs. Level 2:

There are still objections to Level 2 within Blink and other proposed plans (e.g. Implement IME API first), and we don't have an ETA when it will get resolved.

We built a Level 1 spec because it's still a step forward, and we don't want to block it on Level 2 discussions.

[Philip Jägenstedt]

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+...@chromium.org.

[Chong]

On Tuesday, April 18, 2017 at 5:44:29 AM UTC-4, Philip Jägenstedt wrote:

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?

I believe this will remain unresolved at least 1 year, maybe 2 years from now.

Both specs will be maintained, and PRs will be merged to both of them. See commit1 (Level 1 branch) and commit2 (Level 2 branch).

A diff can be found here: https://github.com/w3c/input-events/compare/gh-pages...v1?diff=split&name=v1.

The cardinal difference of the two spec is this PR: https://github.com/w3c/input-events/pull/50.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chong]

Hi Philip, does the clarification below sounds good to you, or is there anything else you want me to do?

Thanks!

[Philip Jägenstedt]

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+...@chromium.org.

[Chong]

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/62

And Blink bug for Level 2 support: https://crbug.com/714791

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.

Thanks for the review! Will plan the shipping in M60.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

On Tue, Apr 25, 2017 at 4:57 AM Chong <cho...@chromium.org> wrote:

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/62

And Blink bug for Level 2 support: https://crbug.com/714791

Thanks Chong!