Intent to Remove: Range.compareNode() and Range.expand()

99 views
Skip to first unread message

Deepak

unread,
May 19, 2015, 7:27:22 AM5/19/15
to blin...@chromium.org

Primary eng (and PM) emails

phi...@opera.com


Summary

Remove Range.compareNode() and Range.expand().


Motivation

These API's have already been deprecated:

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/4VemRjyCth4/av8YNGs-4ykJ


These are non-standard extensions to the Range interface introduced in 2006 and 2009 respectively:

https://trac.webkit.org/changeset/48271
https://trac.webkit.org/changeset/16302

compareNode() was once in Gecko, but was removed in 1.9:
https://developer.mozilla.org/en-US/docs/Web/API/range.compareNode

expand() is a little bit like IE's TextRange.expand():

Neither is currently supported on Range by Firefox or IE, and neither has been standardized:

Compatibility Risk

Exceptions will be thrown, unlimited breakage possible in theory.


Alternative implementation suggestion for web developers

Range.compareNode() => Range.compareBoundaryPoints() is the advice given in the MDN page.


Range.expand() => Selection.modify()



Usage information from UseCounter


Currently both are at 0.0002% usage.
These are both much lower than many removals, with 0.0008% being the highest recorded usage for Range.expand().

Entry on chromestatus.com, crbug.com, or MDN

https://developer.mozilla.org/en-US/docs/Web/API/range.compareNode

http://msdn.microsoft.com/en-us/library/ie/ms536421%28v=vs.85%29.aspx


Requesting approval to remove too?

Yes

Philip Jägenstedt

unread,
May 19, 2015, 7:34:17 AM5/19/15
to Deepak, blink-dev
LGTM1

The Intent to Deprecate thread:

The deprecation happened in M41:

(My name is at the top, but that was copy-pasted from the deprecation message.)

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

TAMURA, Kent

unread,
May 19, 2015, 8:47:32 AM5/19/15
to Philip Jägenstedt, Deepak, blink-dev
LGTM2

--
TAMURA Kent
Software Engineer, Google


Paul Kinlan

unread,
May 19, 2015, 9:00:00 AM5/19/15
to TAMURA, Kent, Philip Jägenstedt, Deepak, blink-dev
Can we get an entry on chromestatus.com for this?  The Intent says "Exceptions will be thrown, unlimited breakage possible in theory." so whilst I think it is obvious that something has happened to developers clearer warning up front will be very useful.

Dimitri Glazkov

unread,
May 19, 2015, 10:31:40 AM5/19/15
to Paul Kinlan, TAMURA, Kent, Philip Jägenstedt, Deepak, blink-dev
Yes, please. And LGTM3.

Philip Jägenstedt

unread,
May 19, 2015, 2:18:34 PM5/19/15
to Dimitri Glazkov, Paul Kinlan, TAMURA, Kent, Deepak, blink-dev

Ramya

unread,
May 26, 2016, 7:38:22 AM5/26/16
to blink-dev, dgla...@chromium.org, paulk...@google.com, tk...@chromium.org, deep...@samsung.com
Hi All,

When I started removing Range.expand() api. I noticed one difference in case of handling text segmentation with separators in between. Range.expand and Selection.modify are behaving differently.
Selection.modify(move) consider separators as part of the word unlike Range.expand which consider separator as a separate word.
Is there any way to achieve Range.expand functionality of selecting current word from any position withing the word using Selection.modify?

Philip Jägenstedt

unread,
May 26, 2016, 9:12:42 AM5/26/16
to Ramya, blink-dev, dgla...@chromium.org, paulk...@google.com, tk...@chromium.org, deep...@samsung.com
It was my doing, but I think it may have been a mistake to deprecate Range.expand() with reference to Selection.modify() before that was added to the spec. (The issue is still open.) I don't know the details well, but there definitely is overlap in functionality here and usage is actually quite close between the two.

The next step, I think, should be to get the relevant implementors for each engine talking to form a plan for these two methods. Perhaps spec'ing both of these would be an option, if they can be built on the same fundamentals?
Reply all
Reply to author
Forward
0 new messages