[css-highlight-api] Should highlightsFromPoint also return ranges under the hit point? · Issue #12031 · w3c/csswg-drafts (original) (raw)

Many use cases for custom highlights that would benefit from highlightsFromPoint also need to determine which ranges are hit from the returned highlights, generally those that have many ranges associated to each highlight.

For example,

• a spellchecker might want to know exactly which word is being clicked/hovered to give suggestions,
• a code editor may have multiple instances of a variable or keyword highlighted with the same highlight and possibly want to emphasize only the one that the user is interacting with,
• a custom find-on-page might want to emphasize one specific match that the user is clicking when there could be many of them in the webpage.

highlightsFromPoint is currently defined as follows in the spec:

partial interface HighlightRegistry {
  sequence<Highlight> highlightsFromPoint(float x, float y, optional HighlightsFromPointOptions options = {});
}

So, implementations that use highlightsFromPoint as above then need some extra computation to identify which range was actually hit, using some workaround with caretPositionFromPoint() or calling getClientRects() on Ranges that are built from the AbstractRanges contained by the highlights hit. This results in more complex code and potentially worse performance than if the ranges were already returned by the API.

One possible definition for highlightsFromPoint that would help with this issue could be written as follows:

partial interface HighlightRegistry {
  sequence<HighlightHitResult> highlightsFromPoint(float x, float y, optional HighlightsFromPointOptions options = {});
};
interface HighlightHitResult {
  Highlight highlight;
  sequence<AbstractRange> ranges; // all of the ranges that were hit for that particular highlight
}

Otherwise, if we keep highlightsFromPoint as is, a function like intersects(x,y) could be added to Highlight, returning a list of ranges in the highlight that intersect the given coordinates, but maybe worth to return both highlights and ranges with the same highlightsFromPoint API for the sake of simplicity.

Interested to hear more thoughts on this. This issue was also brought up before by @schenney-chromium in the highlightsFromPoint I2S.