Add validity criteria for StaticRange

[dandclark]

Add criteria defining whether a StaticRange is valid.

This will be used by the CSS Highlight API to determine whether or not to paint highlights specified by StaticRanges. See https://drafts.csswg.org/css-highlight-api-1/#range-invalidation (which will be updated to point to the DOM spec definition) and the CSSWG resolution that Highlight API should use StaticRanges internally rather than backing them with live Ranges.

Resolves #947.

• At least two implementers are interested (and none opposed):
  • Chromium has implemented Highlight API based on StaticRange using this validity criteria.
  • Webkit has implemented an experimental version of Highlight API, and agreed to the use of StaticRange per the resolution notes.
• Tests are written and can be reviewed and commented upon at:
  • https://github.com/web-platform-tests/wpt/blob/master/css/css-highlight-api/painting/
    • Note, the validity criteria aren't exposed directly, but these Highlight API painting tests depend on the validity criteria to
      determine when to paint or paint a given StaticRange. See in particular custom-highlight-painting-invalidation-*.html
• Implementation bugs are filed (for Highlight API):
  • Chrome: crbug.com/1164461
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1703961
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=204903

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

It would be good to clarify that w3c/csswg-drafts#4597 (comment) is intentional before we move ahead with this, but overall this seems reasonable to me.

Have any measurements been done to show that this is indeed faster?

cc @smaug----

[dandclark]

It would be good to clarify that w3c/csswg-drafts#4597 (comment) is intentional before we move ahead with this, but overall this seems reasonable to me.

Commented here.

Have any measurements been done to show that this is indeed faster?

cc @smaug----

Yes, @ffiori built some benchmarks for this and ran them on Chromium's Highlight API prototype, with the findings documented here. As expected, adding a large number of live Ranges to a document increases the cost of DOM node moves due to the cost of keeping the Ranges up-to-date for every DOM operation. For StaticRange, these costs were avoided, and since it's possible to cache the results of the validity checks StaticRanges were in some cases significantly fater, and never significantly slower.

[smaug----]

Use of StaticRanges forces one to use MutationObserver or other mechanisms to detect mutations in order to keep StaticRanges up-to-date all the time, so the tests were very much unrealistic.
(Also, live Ranges need to observe changes only in the subtree they live in
"The Document stores a collection of pointers to all the Ranges that are alive inside it.
Whenever there’s a DOM mutation that involves deletion/addition of nodes or text for example, all these Ranges are notified about the mutation." smells like some implementations have rather heavyweight Ranges, but that is an implementation detail.)

But anyhow, this change as such is fine.