Intent to Implement and Ship: AbstractRange superclass

123 views
Skip to first unread message

Rome Rome

unread,
Nov 26, 2020, 10:17:31 PM11/26/20
to blink-dev
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

Spec link

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: 
Web developers: Positive
See some comments in the issue.

Is this feature fully tested in Web Platform Tests?
Yes.

Tracking bug URL

Link to entry on the Chrome Platform Status

Manuel Rego Casasnovas

unread,
Nov 27, 2020, 9:13:54 AM11/27/20
to Rome Rome, blink-dev


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

unread,
Nov 30, 2020, 12:58:35 AM11/30/20
to blink-dev, Manuel 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

unread,
Nov 30, 2020, 2:41:14 AM11/30/20
to Jaeyong Bae, blink-dev, Manuel Rego
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

unread,
Nov 30, 2020, 4:25:29 AM11/30/20
to blin...@chromium.org
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

unread,
Nov 30, 2020, 4:59:41 AM11/30/20
to Romederful, blink-dev
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? 
 

Mike West

unread,
Dec 1, 2020, 1:51:47 AM12/1/20
to blink-dev, yo...@yoav.ws, blink-dev, Jaeyong Bae
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

unread,
Dec 1, 2020, 2:47:59 AM12/1/20
to blink-dev, Jaeyong Bae
LGTM2




--
TAMURA Kent
Software Engineer, Google


Romederful

unread,
Dec 1, 2020, 2:51:04 AM12/1/20
to Yoav Weiss, blink-dev


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

unread,
Dec 1, 2020, 3:19:53 AM12/1/20
to Romederful, Yoav Weiss, blink-dev
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

unread,
Dec 1, 2020, 6:29:14 AM12/1/20
to TAMURA, Kent, blink-dev, Jaeyong Bae
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>.
Reply all
Reply to author
Forward
0 new messages