Re: [csswg-drafts] [css-highlight-api] Priority by number or some other method (#4591)

Below are some options that I recall discussing in the past:

(1)
Priority as an attribute on `Highlight`. This is what we have in the spec today. Usage would be:

```
<style>
  p::highlight(foo) {
    background-color:yellow;
  }
  p::highlight(bar) {
    background-color:orange;
  }
</style>
<body>Some text
<script>
  let textNode = document.body.firstChild;

  let r1 = new Range();
  r1.setStart(textNode, 0);
  r1.setEnd(textNode, 6);
  let h1 = new Highlight("foo", r1);

  let r2 = new Range();
  r2.setStart(textNode, 3);
  r2.setEnd(textNode, 9);
  let h2 = new Highlight("bar", r2);

  CSS.highlights.add(h1);
  CSS.highlights.add(h2);

  // If we paint now, h2 will paint above h1 since there is no explicit priority and h2 was registered later.
  
  h1.priority = 1;
  
  // Now h2 will paint above h1.
  
</script>
```

If two highlights have the same priority, the order in which they are registered in the `HighlightRegistry` is used as a tiebreaker.

(2)
Priority as a CSS property. Though this feels more _CSS-y_ and there is prior art for this with `z-index`, this may present a problem for highlight overlays. The css-pseudo-4 spec mentions that there is [a single highlight overlay for the entire document per highlighting type](https://www.w3.org/TR/css-pseudo-4/#highlight-bounds). With priority as a CSS property, authors could write this:
```
#p1::highlight(foo) { priority: 1 }
#p1::highlight(bar) { priority: 2 }
#p2::highlight(foo) { priority: 2 }
#p2::highlight(bar) { priority: 1 }
```
If foo and bar overlap, foo will paint below bar in #p1, but above in #p2. This feels like a violation of the "single overlay for the entire document" concept.

(3)
Do not introduce any CSS property or attribute for priority, and just use the order of highlights in the `HighlightRegistry`. We would instead add methods like the ones below to `HighlightRegistry`, to allow reordering of highlights:
```
append([new highlight])
prepend([new highlight])
insertBefore([new highlight], [reference highlight])
```

This would also mean that `HighlightRegistry` can no longer be `setlike` - it will need a custom implementation.


Amongst the three, I still prefer option 1 - what we have today - since it avoids the problems of option 2, and we can continue to take advantage of `setlike` for the `HighlightRegistry`. Would be great to hear the thoughts of others.

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


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

Received on Wednesday, 3 March 2021 19:53:36 UTC