[css-highlight-api] Change highlightsFromPoint return type #12031 #12215
Conversation
| descending [=priority=] order. | ||
| involving user interaction with [=custom highlights=]. The method returns a [=sequence=] containing {{HighlightHitResult}} objects | ||
| which encapsulate the [=custom highlights=] and their [=ranges=] that are hit at a given <var>x</var>, <var>y</var> coordinate. | ||
| This sequence is ordered in [=priority|reverse paint order=] of its {{HighlightHitResult}}'s [=custom highlights|highlights=]. |
There was a problem hiding this comment.
I'm not sure whether I like the change to show the priority link as reverse paint order. In https://drafts.csswg.org/css-highlight-api-1/#priorities we basically define the paint order as being derived from the concept of https://drafts.csswg.org/css-highlight-api-1/#priority, so I think it's more direct just to keep the link as having that same word. That way there's no question of which concept is derived from which.
I don't feel super strongly about this though, so if you disagree feel free to disregard this comment.
| as <var>h2</var> has higher priority than <var>h1</var>. | ||
| * <code>[ HighlightHitResult {highlight: <var>h1</var>, ranges: [<var>r1</var>]} ]</code>, if the user clicks on character "a". | ||
| Note that only <var>r1</var> is included in the {{HighlightHitResult}} returned since that's the only range in <var>h1</var> that was hit. | ||
| * <code>[ HighlightHitResult {highlight: <var>h2</var>, ranges: [<var ignore=''>r2</var>]}, HighlightHitResult {highlight: <var>h1</var>, ranges: [<var>r1</var>]} ]</code>, |
There was a problem hiding this comment.
What does the ignore='' here do?
There was a problem hiding this comment.
This is to supress a warning from the preprocessor because this variable is used only once, but I wanted to keep the <var> tag on it so it gets the same style as other variables in the spec.
| * <code>[ HighlightHitResult {highlight: <var>h1</var>, ranges: [<var>r1</var>]} ]</code>, if the user clicks on character "a". | ||
| Note that only <var>r1</var> is included in the {{HighlightHitResult}} returned since that's the only range in <var>h1</var> that was hit. | ||
| * <code>[ HighlightHitResult {highlight: <var>h2</var>, ranges: [<var ignore=''>r2</var>]}, HighlightHitResult {highlight: <var>h1</var>, ranges: [<var>r1</var>]} ]</code>, | ||
| if the user clicks on character "b", as <var>h2</var> has higher priority than <var>h1</var>. | ||
| * <code>[]</code>, if the user clicks on character "c". |
There was a problem hiding this comment.
Might not hurt to expand the example to clicking on d for completeness and to show how the range changes.
| * The topmost [=box=] in the [=viewport=] in paint order that would be a target for hit testing at coordinates <var>x</var>,<var>y</var> when applying | ||
| the [=transforms=] that apply to the descendants of the viewport, has an element associated to it that's in a [=shadow tree=] whose | ||
| [=shadow root=] is not [=list/contains|contained by=] <var>options</var>.<var>shadowRoots</var>. | ||
| 1. Otherwise, return a [=sequence=] of {{HighlightHitResult}} objects ordered in [=priority|reverse paint order=] of their <var>highlight</var> attributes, |
There was a problem hiding this comment.
I think this semi-declarative way of defining this is getting somewhat unclear with the added layer of including the ranges. For example it's no longer obvious why a HighlightHitResult for a given Highlight would be included or not, because now the question of whether to include something or not is focused on the ranges. The point that a HighlightHitResult is only included if the resulting ranges array is empty could be lost, it's just kind of implied that ranges is non-empty.
The bit about allowing a Range object to be constructed from a StaticRange and then using the range in the next bullet point is also hard to follow, it's like a bit of imperative logic mixed in with the declarative.
I think it's worth trying a more fully imperative way of defining this, a bit closer to how it'd actually be implemented. Basically:
- Let
resultbe an empty list. - For each Highlight in our registry:
- Create a HighlightHitResult with the given highlight.
- For each Range in the Highlight:
- Do the hit test, and add range to HighlightHitResult if it passes.
- For each Range in the Highlight:
- If the HighlightHitResult has non-empty
ranges, add it toresult.
- Create a HighlightHitResult with the given highlight.
- Sort
resultby priority of the highlights // or alternatively, the outerforloop could iterate the highlights in prority order - Return result.
[css-highlight-api] Change highlightsFromPoint return type #12031
As discussed and resolved in #12031, this PR changes the return type for
highlightsFromPointtosequence<HighlightHitResult>to include the ranges that are hit at a given point in addition to the custom highlights.This PR also resolves issues #12045 #12003 #12002.