- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Aug 2021 16:28:39 +0000
- To: public-css-archive@w3.org
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> <TabAtkins> Topic: highlight API<br> <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/4597<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/4597<br> <TabAtkins> dandclark: This was originally what the criteria was to invalidate a static range during DOM mutations<br> <TabAtkins> dandclark: discussion evolved into use of StaticRange more generally<br> <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> <TabAtkins> dandclark: I want to advocate we use statics internally<br> <TabAtkins> dandclark: One for perf; static range is better for perf in some cases when there's a lot of DOM mutations<br> <TabAtkins> dandclark: Team has done some benchmarks and shown the perf diffs aren't theoretical<br> <TabAtkins> dandclark: And issues with invalidation of static ragnes during paint time can be addressed with invalidation caches<br> <chrishtr> q+<br> <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> <TabAtkins> dandclark: Second is some issues sanketj pointed out<br> <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> <TabAtkins> dandclark: Like if a highlihgt is unregistered, should we maintain it? Highlight can be reregistered, unsure what the lifetime is<br> <TabAtkins> dandclark: So I'd like to get agreement that the internal range is indeed static<br> <florian> q?<br> <Rossen_> ack chrishtr<br> <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> <TabAtkins> chrishtr: [missed]<br> <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> <TabAtkins> dandclark: You can largely cache validity status and be fine; if there's no dom mutations you're guaranteed right<br> <florian> q+<br> <TabAtkins> chrishtr: But if the dom mutation was non-trivial, the UA might have to treewalk in the worst case?<br> <TabAtkins> dandclark: Yeah<br> <TabAtkins> chrishtr: And you couldn't avoid that situation?<br> <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> <TabAtkins> chrishtr: So the script usually will make a static range and then immediately add it to the doc<br> <TabAtkins> dandclark: yeah<br> <GameMaker> q+<br> <Rossen_> ack florian<br> <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> <TabAtkins> florian: Live ranges can be costly, and it might not even be a useful cost<br> <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> <TabAtkins> florian: So paying the cost of updating the live range, only to immediately discard it and regen the range, is silly.<br> <sanketj> +1 to the proposed resolution<br> <chrishtr> +1<br> <GameMaker> +1<br> <TabAtkins> Rossen_: Any furhter comments?<br> <Rossen_> q?<br> <Rossen_> ack GameMaker<br> <TabAtkins> GameMaker: Agreeement; webkit has the same perf issues that Chrome does, so +1<br> <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> <TabAtkins> florian: Do we think we need a spec change to reflect this? Or is the spec already sufficiently implying this?<br> <TabAtkins> dandclark: I think the spec is clear as-is; we'd only need a change if we decided the other way<br> <TabAtkins> dandclark: There's another issues about invalidation we coudl discuss; it was the original issue.<br> <TabAtkins> sanketj: I think it would be good to have a note about using static ranges internally<br> <TabAtkins> sanketj: So for interop we should have an explanation<br> <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> <TabAtkins> dandclark: I can look over it<br> <Rossen_> ack fantasai<br> <Zakim> fantasai, you wanted to ask about publication<br> <TabAtkins> fantasai: last pub of this draft was Dec 2020; given changes, we should get an update onto TR<br> <TabAtkins> fantasai: ED claims there's only been minor changes since last WD, that probably isn't true<br> <TabAtkins> florian: agree. i'll start making sure the changes section is up to date<br> <TabAtkins> Rossen_: Should we get a resolution to republish the WD when it's ready?<br> <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