Re: [csswg-drafts] [css-highlight-api] invalidation of static ranges (#4597)

The CSS Working Group just discussed `Invalidation of Static Ranges`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Invalidation of Static Ranges<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/4597#issuecomment-892202307<br>
&lt;fantasai> dandclark: Static ranges can get into weird states, like if I remove one boundary from the DOM<br>
&lt;fantasai> dandclark: Sanket came up with criteria for deciding if a range is valid or invalid<br>
&lt;fantasai> dandclark: but the qustion is, if user adds range to a highlight should we use a live range, or use static range internally<br>
&lt;fantasai> dandclark: reason to use live range, don't have to check validity in the same way because they're kept up to date<br>
&lt;fantasai> dandclark: We discussed awhile, and decided not to back static ranges with a live range<br>
&lt;fantasai> dandclark: first, perf reasons -- live ranges, they can slow down DOM mutations because live ranges have to be notified every time there's a DOM mutation<br>
&lt;fantasai> dandclark: static range doesn't have that issue<br>
&lt;fantasai> dandclark: we did some research showing that this perf issue is observable<br>
&lt;fantasai> dandclark: and we also found that with caching, it's possible to cache static range validdity<br>
&lt;fantasai> dandclark: which reduces perf cost during painting<br>
&lt;fantasai> dandclark: but if they were backed by live ranges internally, that wouldn't hold<br>
&lt;fantasai> dandclark: because DOM mutations would have to update, so lose perf benefits<br>
&lt;fantasai> dandclark: Sanket also raised some issues with using live ranges internally<br>
&lt;fantasai> dandclark: Authors don't have direct references to those live ranges<br>
&lt;fantasai> dandclark: so difficult, how would they remove or modify a highlight that they added?<br>
&lt;fantasai> dandclark: even if we added a map, can become out of sync with tree<br>
&lt;fantasai> dandclark: and not clear when safe to drop live range, because author might de-regeister and re-register a static range<br>
&lt;fantasai> dandclark: so confusing developer-confusing scenarios there, tricky answers for spec<br>
&lt;fantasai> dandclark: so proposal is to allow static ranges and live ranges to be added to highlights<br>
&lt;fantasai> dandclark: and there's no live range backing for static ranges<br>
&lt;fantasai> astearns: My first question was, can developer use either<br>
&lt;fantasai> astearns: is it clear to devs that live range could have perf implications?<br>
&lt;fantasai> dandclark: It's in line with current use of live ranges<br>
&lt;fantasai> dandclark: Spec issue states that static ranges solve this perf<br>
&lt;fantasai> dandclark: Use of live ranges in genera, here or otherwise, has these perf costs<br>
&lt;fantasai> dandclark: I think it's a documentation and devrel issue<br>
&lt;fantasai> dandclark: of when live ranges vs static ranges are appropriate<br>
&lt;fantasai> sanketj: HTML doc also mentions this (?)<br>
&lt;fantasai> sanketj: It has been documented<br>
&lt;fantasai> sanketj: Static ranges are fairly new concept, previously only had option of live ranges<br>
&lt;fantasai> astearns: OK, out of time<br>
&lt;fantasai> astearns: my understanding is that with this impl experience, you would like to close issue no change?<br>
&lt;fantasai> dandclark: yes<br>
&lt;fantasai> astearns: OK, we'll expect to close no change, and will resolve next week<br>
&lt;fantasai> Meeting closed.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4597#issuecomment-901283465 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 18 August 2021 17:09:51 UTC