[css-highlight-api] triggering restyling/repainting

[frivoal]

The properties controlled by the ::highlight() pseudo cannot affect layout, so there's not going to be a full reflow when something change, but they can still cause visual changes, so we need to be clear about when a re-computation of styles and a repaint happen.

In addition to DOM changes that would cause a restyling anyway, the following can cause a need for restyling/repainting:

• adding or removing a HighlightRangeGroup to CSS.highlights
• adding or removing a range to a HighlightRangeGroup in CSS.highlights
• Changing the boundary points of a range in a HighlightRangeGroup in CSS.highlights
• Changing the priority of a HighlightRangeGroup in CSS.highlights
• Changing the style property of a HighlightRangeGroup in CSS.highlights

Are any or all of things things synchronously triggering a restyle/repaint? Probably not, but what should the spec say?

[dandclark]

I was discussing this with some other Edge folks interested in this API.

It doesn't seem like any of these would need to trigger a synchronous repaint, and that modifications to these would be similar to CSS OM modifications, or changes to HTMLElement.Style. Not sure about the spec wording, but as far as the browser implementation goes, the affected area would be marked as needing a repaint which would occur whenever the browser needed to compute another frame.

As a sidenote, I guess the fifth bullet no longer applies since the spec no longer has that style property.

[frivoal]

@dandclark That seems reasonable to me. From your point of view, would you say the text in https://drafts.csswg.org/css-highlight-api-1/#repaint already achieves that, or would you like to see an explicit statement like:

This repaint is asynchronous, and the APIs mentioned above must not block while waiting for the repaint to happen.

@megangardner, @sanketj any thoughts on that?

[dandclark]

I think it's probably a good idea to include a note like this, just so it's super clear that user agents don't need to do any synchronous work.

[sanketj]

I agree that highlight modifications should not trigger sync repaints. The implementation we're working on in Chromium will always paint async. I think it would be good to add some explicit text mandating this, because if other UAs end up doing sync painting, we may see unexpected interop differences.

[dandclark]

Here's a PR adding the line suggested by @frivoal above: #6987
I've marked this Agenda+, but am not sure if this meets the bar of something that needs to be resolved on in a meeting -- @frivoal / @sanketj, feel free to go ahead and review and merge if you don't feel that this needs further discussion.

[css-meeting-bot]

The CSS Working Group just discussed [css-highlight-api] triggering restyling/repainting.

The full IRC log of that discussion

topic: [css-highlight-api] triggering restyling/repainting
github: https://github.com//issues/4596
??: Merged the PR to resolve this, unsure if Florian has anything to add here?
[no, I'm good]