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

[Deepak]

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():

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

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

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

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

https://www.chromestatus.com/metrics/feature/timeline/popularity/392

https://www.chromestatus.com/metrics/feature/timeline/popularity/393

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]

LGTM1

The Intent to Deprecate thread:

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

The deprecation happened in M41:

https://codereview.chromium.org/819093002

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

LGTM2

--

TAMURA Kent
Software Engineer, Google

[Paul Kinlan]

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]

Yes, please. And LGTM3.

[Philip Jägenstedt]

I've created https://www.chromestatus.com/features/4846282115907584

[Ramya]

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.

Ex: https://jsfiddle.net/tjtwzxd8/6/ 

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]

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?