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

The CSS Working Group just discussed `highlight API`, and agreed to the following:

* `RESOLVED: When an author uses a static range for highlight API, it should actually be a static range internally, not backed by a hidden live range.`
* `RESOLVED: Publish a new Highlight API WD when changes are made`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: highlight API<br>
&lt;Rossen_> github: https://github.com/w3c/csswg-drafts/issues/4597<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/4597<br>
&lt;TabAtkins> dandclark: This was originally what the criteria was to invalidate a static range during DOM mutations<br>
&lt;TabAtkins> dandclark: discussion evolved into use of StaticRange more generally<br>
&lt;TabAtkins> dandclark: So when an author adds a staticrange to a highlight, should we internally back it with a live range? Or just let it stay static<br>
&lt;TabAtkins> dandclark: I want to advocate we use statics internally<br>
&lt;TabAtkins> dandclark: One for perf; static range is better for perf in some cases when there's a lot of DOM mutations<br>
&lt;TabAtkins> dandclark: Team has done some benchmarks and shown the perf diffs aren't theoretical<br>
&lt;TabAtkins> dandclark: And issues with invalidation of static ragnes during paint time can be addressed with invalidation caches<br>
&lt;chrishtr> q+<br>
&lt;TabAtkins> dandclark: So if they're backed with live ranges internally, we pretty much lose all the benefits and there's no reason to support it<br>
&lt;TabAtkins> dandclark: Second is some issues sanketj pointed out<br>
&lt;TabAtkins> dandclark: If a static is backed internally with a live range, the author doesn't ahve a ref to it, so how do they manipulate this<br>
&lt;TabAtkins> dandclark: Like if a highlihgt is unregistered, should we maintain it? Highlight can be reregistered, unsure what the lifetime is<br>
&lt;TabAtkins> dandclark: So I'd like to get agreement that the internal range is indeed static<br>
&lt;florian> q?<br>
&lt;Rossen_> ack chrishtr<br>
&lt;TabAtkins> chrishtr: So your proposal is that the static range is not live internally, and as a result, when the highlight api uses a static range it's ignored if it's invalid<br>
&lt;TabAtkins> chrishtr: [missed]<br>
&lt;TabAtkins> dandclark: There are some cases like "start before end" that you might have to treewalk to determine; it's not constant-time to determine<br>
&lt;TabAtkins> dandclark: You can largely cache validity status and be fine; if there's no dom mutations you're guaranteed right<br>
&lt;florian> q+<br>
&lt;TabAtkins> chrishtr: But if the dom mutation was non-trivial, the UA might have to treewalk in the worst case?<br>
&lt;TabAtkins> dandclark: Yeah<br>
&lt;TabAtkins> chrishtr: And you couldn't avoid that situation?<br>
&lt;TabAtkins> dandclark: I think UAs could in theory do some optimizations, but the simplest way is to just cache the data; you won't have mutations between every paint in practice<br>
&lt;TabAtkins> chrishtr: So the script usually will make a static range and then immediately add it to the doc<br>
&lt;TabAtkins> dandclark: yeah<br>
&lt;GameMaker> q+<br>
&lt;Rossen_> ack florian<br>
&lt;TabAtkins> florian: agree. I think this is the right thing to do; it's why we proposed having static ranges in the first place<br>
&lt;TabAtkins> florian: Live ranges can be costly, and it might not even be a useful cost<br>
&lt;TabAtkins> florian: If the DOM changes and the UA updates the range, whether or not the updated range is what the author actually wanted isn't clear<br>
&lt;TabAtkins> florian: So paying the cost of updating the live range, only to immediately discard it and regen the range, is silly.<br>
&lt;sanketj> +1 to the proposed resolution<br>
&lt;chrishtr> +1<br>
&lt;GameMaker> +1<br>
&lt;TabAtkins> Rossen_: Any furhter comments?<br>
&lt;Rossen_> q?<br>
&lt;Rossen_> ack GameMaker<br>
&lt;TabAtkins> GameMaker: Agreeement; webkit has the same perf issues that Chrome does, so +1<br>
&lt;TabAtkins> RESOLVED: When an author uses a static range for highlight API, it should actually be a static range internally, not backed by a hidden live range.<br>
&lt;TabAtkins> florian: Do we think we need a spec change to reflect this? Or is the spec already sufficiently implying this?<br>
&lt;TabAtkins> dandclark: I think the spec is clear as-is; we'd only need a change if we decided the other way<br>
&lt;TabAtkins> dandclark: There's another issues about invalidation we coudl discuss; it was the original issue.<br>
&lt;TabAtkins> sanketj: I think it would be good to have a note about using static ranges internally<br>
&lt;TabAtkins> sanketj: So for interop we should have an explanation<br>
&lt;TabAtkins> florian: We say already that when you use a static range they shouldn't be updated, but we can work over the note<br>
&lt;TabAtkins> dandclark: I can look over it<br>
&lt;Rossen_> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to ask about publication<br>
&lt;TabAtkins> fantasai: last pub of this draft was Dec 2020; given changes, we should get an update onto TR<br>
&lt;TabAtkins> fantasai: ED claims there's only been minor changes since last WD, that probably isn't true<br>
&lt;TabAtkins> florian: agree. i'll start making sure the changes section is up to date<br>
&lt;TabAtkins> Rossen_: Should we get a resolution to republish the WD when it's ready?<br>
&lt;TabAtkins> RESOLVED: Publish a new Highlight API WD when changes are made<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-905688814 using your GitHub account


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

Received on Wednesday, 25 August 2021 16:28:42 UTC