Intent to Implement and Ship: AbstractRange superclass

[Rome Rome]

Contact emails
jdrag...@gmail.com

Feature summary

The bits shared between StaticRange and Range objects are put on a shared superclass named AbstractRange.

Motivation

According to the StaticRange.idl, there are some duplicate methods with Range.

Create an AbstractRange superclass and move some of the methods on Range that we want on StaticRange to the superclass as well. StaticRange and Range both inherit from AbstractRange.

To reclassify Range objects as "live ranges" rather than "ranges". this can be communicated more clearly to the user.

Explainer

https://github.com/w3c/staticrange/issues/1

Spec link

https://dom.spec.whatwg.org/#interface-abstractrange

TAG Review 

Not needed since it's an existing spec discussed at WHATWG.

Interoperability and Compatibility Risks 

Compatibility:

As an abstract interface, we will not directly instantiate an object of type AbstractRange. 

So, we should change the overlapping code in the Range and StaticRange interfaces.

Interoperability: 

Firefox: Public support

Safari: Public support

Edge:  Implemented this in Edge

Web developers: Positive

See some comments in the issue.

Is this feature fully tested in Web Platform Tests?

Yes.

https://wpt.fyi/results/dom/idlharness.window.html%3Fexclude%3DNode

https://github.com/web-platform-tests/wpt/pull/9967

Tracking bug URL

https://bugs.chromium.org/p/chromium/issues/detail?id=820947

Link to entry on the Chrome Platform Status

https://chromestatus.com/features/5633112799182848

[Manuel Rego Casasnovas]

On 26/11/2020 07:13, Rome Rome wrote:
> *Explainer*
> https://github.com/w3c/staticrange/issues/1

This is not a explainer, it's usually better to have a small summary in
a separated document (or an inline comment in the intent if that's
enough).

> *Interoperability and Compatibility Risks *

> Compatibility:
> As an abstract interface, we will not directly instantiate an object of
> type AbstractRange.
> So, we should change the overlapping code in the Range and StaticRange
> interfaces.

Does it has any impact on current websites? Would anything stop working?

> Interoperability:
> Firefox: Public support
> <https://wpt.fyi/results/dom/idlharness.window.html%3Fexclude%3DNode>
> Safari: Public support
> <https://wpt.fyi/results/dom/idlharness.window.html%3Fexclude%3DNode>

More than public support it seems it has been shipped in both, or am I
wrong?

Bye,
Rego

[Jaeyong Bae]

On 27/11/2020 11:13, Manuel Rego wrote: 

On 26/11/2020 07:13, Rome Rome wrote:
> *Explainer*
> https://github.com/w3c/staticrange/issues/1

This is not a explainer, it's usually better to have a small summary in
a separated document (or an inline comment in the intent if that's
enough).

 Thanks for the guidance. I wonder omit the Explainer in this.

 

> *Interoperability and Compatibility Risks *
> Compatibility:
> As an abstract interface, we will not directly instantiate an object of
> type AbstractRange.
> So, we should change the overlapping code in the Range and StaticRange
> interfaces.

Does it has any impact on current websites? Would anything stop working?

No, the current websites can keep the code. Because 'Range' and 'StaticRange' can be used the same as before. 

This change will add the abstract superclass and inherits it.

> Interoperability:
> Firefox: Public support
> <https://wpt.fyi/results/dom/idlharness.window.html%3Fexclude%3DNode>
> Safari: Public support
> <https://wpt.fyi/results/dom/idlharness.window.html%3Fexclude%3DNode>

More than public support it seems it has been shipped in both, or am I
wrong?

You're the boss.  I will change 'Public support' to 'Shipped/Shipping' both.

 

Bye,
Rego

Thank you very much, Rego. 

[Yoav Weiss]

On Mon, Nov 30, 2020 at 7:00 AM Jaeyong Bae <jdrag...@gmail.com> wrote:

On 27/11/2020 11:13, Manuel Rego wrote: 

On 26/11/2020 07:13, Rome Rome wrote:
> *Explainer*
> https://github.com/w3c/staticrange/issues/1

This is not a explainer, it's usually better to have a small summary in
a separated document (or an inline comment in the intent if that's
enough).

 Thanks for the guidance. I wonder omit the Explainer in this.

As Rego said, it's better to include an explainer, even if a short, inlined one, so that reviewers (and the public) can quickly understand what it is you're trying to ship and why.

 

> *Interoperability and Compatibility Risks *
> Compatibility:
> As an abstract interface, we will not directly instantiate an object of
> type AbstractRange.
> So, we should change the overlapping code in the Range and StaticRange
> interfaces.

Does it has any impact on current websites? Would anything stop working?

No, the current websites can keep the code. Because 'Range' and 'StaticRange' can be used the same as before. 

This change will add the abstract superclass and inherits it.

> Interoperability:
> Firefox: Public support
> <https://wpt.fyi/results/dom/idlharness.window.html%3Fexclude%3DNode>
> Safari: Public support
> <https://wpt.fyi/results/dom/idlharness.window.html%3Fexclude%3DNode>

More than public support it seems it has been shipped in both, or am I
wrong?

You're the boss.  I will change 'Public support' to 'Shipped/Shipping' both.

 

Bye,
Rego

Thank you very much, Rego. 

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/efe97b91-8b9f-465a-9671-412afb48beb1n%40chromium.org.

[Romederful]

On 27/11/2020 17:33, Yoav Weiss wrote:

On Mon, Nov 30, 2020 at 9:07 AM Romederful <jdrag...@gmail.com> wrote:

On 27/11/2020 11:13, Yoav Weiss wrote:

On Mon, Nov 30, 2020 at 7:00 AM Jaeyong Bae <jdrag...@gmail.com> wrote:

On 27/11/2020 11:13, Manuel Rego wrote: 

On 26/11/2020 07:13, Rome Rome wrote:
> *Explainer*
> https://github.com/w3c/staticrange/issues/1

This is not a explainer, it's usually better to have a small summary in
a separated document (or an inline comment in the intent if that's
enough).

 Thanks for the guidance. I wonder omit the Explainer in this.

As Rego said, it's better to include an explainer, even if a short, inlined one, so that reviewers (and the public) can quickly understand what it is you're trying to ship and why.

Thanks Yoav :) I'm going to change it like below.

Explainer
Implement and ship superclass named AbstractRange, StaticRange and Range both inherit from AbstractRange.

The bits shared between StaticRange and Range objects are put on a shared AbstractRange.

What is the use case for this? What would it enable developers to do?

How would developer code need to change as a result?

 

AbstractRange is abstract interface, so developers will not directly instantiate an object of type AbstractRange.
This means that developers will use the Range or StaticRange interfaces instead. 
As a result, I think developer code related to Range or StaticRange can be kept without any changes.

[Yoav Weiss]

On Mon, Nov 30, 2020 at 10:25 AM Romederful <jdrag...@gmail.com> wrote:

On 27/11/2020 17:33, Yoav Weiss wrote:

On Mon, Nov 30, 2020 at 9:07 AM Romederful <jdrag...@gmail.com> wrote:

On 27/11/2020 11:13, Yoav Weiss wrote:

On Mon, Nov 30, 2020 at 7:00 AM Jaeyong Bae <jdrag...@gmail.com> wrote:

On 27/11/2020 11:13, Manuel Rego wrote: 

On 26/11/2020 07:13, Rome Rome wrote:
> *Explainer*
> https://github.com/w3c/staticrange/issues/1

This is not a explainer, it's usually better to have a small summary in
a separated document (or an inline comment in the intent if that's
enough).

 Thanks for the guidance. I wonder omit the Explainer in this.

As Rego said, it's better to include an explainer, even if a short, inlined one, so that reviewers (and the public) can quickly understand what it is you're trying to ship and why.

Thanks Yoav :) I'm going to change it like below.

Explainer
Implement and ship superclass named AbstractRange, StaticRange and Range both inherit from AbstractRange.

The bits shared between StaticRange and Range objects are put on a shared AbstractRange.

What is the use case for this? What would it enable developers to do?

How would developer code need to change as a result?

 

AbstractRange is abstract interface, so developers will not directly instantiate an object of type AbstractRange.
This means that developers will use the Range or StaticRange interfaces instead. 
As a result, I think developer code related to Range or StaticRange can be kept without any changes.

Do I understand correctly that the AbstractRange class will be web exposed?

Are developers supposed to use it in some way? 

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOhF%3Dqx7KChOPTCQLOhFrGO9a9M7aeV-u7xw0JfzMTVMSjNROw%40mail.gmail.com.

[Mike West]

LGTM1. I agree that a TAG review would be unhelpful for this change that landed in DOM ~2 years ago, and is already shipping interoperably in two other engines. This seems like a small change that will have little practical effect, other than matching the prototype chains shipping today in Firefox and Safari. Aligning with that behavior seems like a win, at least insofar as checks like `instanceof` are concerned.

Thanks for helping Chromium catch up, and smoothing out the differences between engines.

-mike

[TAMURA, Kent]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb03156e-8a73-4c3b-8bf0-0e0d6678bbe5n%40chromium.org.

--

TAMURA Kent
Software Engineer, Google

[Romederful]

2020년 11월 30일 (월) 오후 6:59, Yoav Weiss <yo...@yoav.ws>님이 작성:

If the meaning of web exposed is that developers use AbstractRange directly, 

I think it doesn't.

[Anne van Kesteren]

On Tue, Dec 1, 2020 at 8:50 AM Romederful <jdrag...@gmail.com> wrote:
> If the meaning of web exposed is that developers use AbstractRange directly,
> I think it doesn't.

FWIW, AbstractRange is web exposed and would allow developers to add
properties to it that can be used on instances of Range & StaticRange.
Quite similar to the relation between CharacterData and Text &
Comment. Happy to finally see this in all engines!

[Manuel Rego Casasnovas]

LGTM3

On 01/12/2020 08:47, TAMURA, Kent wrote:
> LGTM2
>
>
> On Tue, Dec 1, 2020 at 3:51 PM Mike West <mk...@chromium.org
> <mailto:mk...@chromium.org>> wrote:
>
> LGTM1. I agree that a TAG review would be unhelpful for this change
> that landed in DOM ~2 years ago, and is already shipping
> interoperably in two other engines. This seems like a small change
> that will have little practical effect, other than matching the
> prototype chains shipping today in Firefox and Safari. Aligning with
> that behavior seems like a win, at least insofar as checks like
> `instanceof` are concerned.
>
> Thanks for helping Chromium catch up, and smoothing out the
> differences between engines.
>
> -mike
>
> On Monday, November 30, 2020 at 10:59:41 AM UTC+1 yo...@yoav.ws

> <mailto:yo...@yoav.ws> wrote:
>
> On Mon, Nov 30, 2020 at 10:25 AM Romederful <jdrag...@gmail.com>
> wrote:
>
> On 27/11/2020 17:33, Yoav Weiss wrote:
>
>
> On Mon, Nov 30, 2020 at 9:07 AM Romederful
> <jdrag...@gmail.com> wrote:
>
> On 27/11/2020 11:13, Yoav Weiss wrote:
>
>
>
> On Mon, Nov 30, 2020 at 7:00 AM Jaeyong Bae
> <jdrag...@gmail.com> wrote:
>
> On 27/11/2020 11:13, Manuel Rego wrote:
>
>
> On 26/11/2020 07:13, Rome Rome wrote:
> > *Explainer*
> >
> https://github.com/w3c/staticrange/issues/1
> <https://github.com/w3c/staticrange/issues/1>
>
>
> This is not a explainer, it's usually
> better to have a small summary in
> a separated document (or an inline
> comment in the intent if that's
> enough).
>
>
>  Thanks for the guidance. I wonder omit the

> *Explainer *in this*.*

>
>
> As Rego said, it's better to include an
> explainer, even if a short, inlined one, so that
> reviewers (and the public) can quickly
> understand what it is you're trying to ship and why.
>
>
> Thanks Yoav :) I'm going to change it like below.
>

> *Explainer
> *Implement and ship superclass named AbstractRange,

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/efe97b91-8b9f-465a-9671-412afb48beb1n%40chromium.org?utm_medium=email&utm_source=footer>.

>
> --
> 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.
>
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOhF%3Dqx7KChOPTCQLOhFrGO9a9M7aeV-u7xw0JfzMTVMSjNROw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOhF%3Dqx7KChOPTCQLOhFrGO9a9M7aeV-u7xw0JfzMTVMSjNROw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

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

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb03156e-8a73-4c3b-8bf0-0e0d6678bbe5n%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb03156e-8a73-4c3b-8bf0-0e0d6678bbe5n%40chromium.org?utm_medium=email&utm_source=footer>.

>
>
>
> --
> TAMURA Kent
> Software Engineer, Google
>
>

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

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHsQBTFgLZUzCbQg6xrUxSvpUQSHj6rLTMidLTeU3O79Q%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHsQBTFgLZUzCbQg6xrUxSvpUQSHj6rLTMidLTeU3O79Q%40mail.gmail.com?utm_medium=email&utm_source=footer>.