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

That's why I had proposed the StaticRange validation criteria in whatwg/dom#947. That should cover the shadow DOM cases and the overlapped endpoints case. That criteria seems pretty generic, not highlight API specific, hence I proposed adding those to the StaticRange spec. To validate static highlights, we would need to run those checks, as well as an additional check for #4598. Of course, all of the above is only applicable if the highlight API paints static ranges directly, instead of using live ranges internally.

If we used live ranges internally, there are some additional questions we'll need to answer:
- How would authors be able to remove a range from a `Highlight`? If the static ranges passed into the `Highlight` constructor are just inputs that the `Highlight` uses to create its own internal live ranges that are not exposed to JS, then authors don't have access to the actual range objects being painted and can't remove them individually.
- At what point would we create the internal live ranges maintained by the highlight? A highlight is only painted if it is registered (ie. added to `CSS.highlights`). If we create the internal ranges when we construct the `Highlight` object, then we start paying the cost of maintaining them during DOM mutations, even though the highlight isn't being painted yet. Instead, we could create the internal ranges only when the `Highlight` is added to `CSS.highlights`. However, this would require storing the passed-in static ranges internally until that moment.
- At what point do we "drop" the internal live ranges? A `Highlight` can also be deregistered (ie. removed from `CSS.highlights`). Let's say that after the `Highlight` is removed, we just wait for it to go out of scope and get GC'ed, which is when the internal ranges will be released. Until these ranges are garbage collected, we are still paying the cost to maintain them during DOM mutations, even though the highlight is no longer registered. Instead, we could drop the ranges when the `Highlight` is deregistered. However, how would we re-establish the old range positions if the `Highlight` is subsequently re-registered?

With regards to the performance tradeoff, we are starting prototyping in Chromium, so we can run some perf tests to compare the static range painting overhead vs. the added maintenance cost during DOM mutations if we used live ranges internally. Hopefully that can give us a better idea on which way to go. If other implementors could do the same, that would be great too.

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


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

Received on Wednesday, 17 February 2021 06:48:21 UTC