- From: Dan Clark via GitHub <sysbot+gh@w3.org>
- Date: Tue, 03 Aug 2021 22:15:41 +0000
- To: public-css-archive@w3.org
@ffiori ran some [experiments](https://docs.google.com/document/d/1byMUPIcx2cldNlppyvRP3HX9w1NIryO_F7mgQNytMzs/edit#heading=h.7nki9mck5t64) and confirmed that at least in Chromium, 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. On the other hand, with an implementation that caches StaticRange validity there is no scenario where StaticRange has significantly worse performance for Highlights. It would be interesting to know if WebKit has done any similar experiments on their implementation. There are realistic scenarios where a site might want to use a large number of Highlights, like a site with a lot of text implementing its own find-on-page. Allowing the use of StaticRange, without creating StaticRanges internally, could be helpful for performance in such scenarios. I also agree with @frivoal's reply above that if we're always going to use live Ranges internally anyway, then I don't see any reason to include StaticRange in the API. -- GitHub Notification of comment by dandclark Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4597#issuecomment-892202307 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 3 August 2021 22:15:42 UTC