[css-highlight-api] position of the custom highlights relative to the built in ones

[frivoal]

In the third bullet point of https://drafts.csswg.org/css-highlight-api-1/#painting, the spec says that the custom highlights are above the builtin ones.

Is that right? Should they be below instead, to make sure that highlights provided by the UA are never hidden?

See also #4593 and #4594.

[hober]

1. For us, selection is special and has to win over all others. This is an implementation constraint on some platforms that would be prohibitively difficult to change.
2. The built-in ones should probably be consistent, either all winning over the custom ones or all losing.

Given these two points, I think the right thing to do here is for native to always win, and among native, for selection to always win (so selection wins overall, always).

[sanketj]

Yes, I think the UA's highlights should not be hidden by default, therefore custom highlights should paint below native highlights.

I couldn't find any use cases that require custom highlights to go above native highlights. If we do find such use cases in the future, then we can consider adding a new property/attribute, so that the custom ones can at least go above the non-selection native highlights.

[css-meeting-bot]

The CSS Working Group just discussed [css-highlight-api] position of the custom highlights relative to the built in ones, and agreed to the following:

• RESOLVED: custom highlights will always go below native highlights

The full IRC log of that discussion

<dael> Topic: [css-highlight-api] position of the custom highlights relative to the built in ones
<dael> github: https://github.com//issues/4595
<dael> smfr: css pseudo spec spec order highlights. selection is on top, then target text, spelling error, grammer error. Where does ::highlight fit?
<astearns> s/smfr/sanketj
<dael> sanketj: Proposal is below the native ones. WOuldn't want author defined highlight to surpress
<florian> q+
<fantasai> wfm
<astearns> ack florian
<dael> florian: Sounds good for default terms. If it's possible to override is more subtle. Being at the bottom by default makes sense. At least on one Apple system you can't draw over selection highlight
<dael> florian: As to if it should be overrideable...going over selection you can't. For spelling error you can imagine author wanting custom spelling but default gramma. Without ability to go on top of some native you can't
<dael> sanketj: Fair. Did experienment to see if wanted tosupport interleaving. If you want to go above others we can't find scenario and don't have requests so thought we could solve that down the line and define the option later
<dael> fantasai: Agree. I would note effects of highlights to stack so some effects will override but some will stack
<dael> florian: I'm fine with proposal. I want to make sure we talk now b/c we have related issues about the API to determine what's on top. There were suggestions for negative to o under and positive above, if we say never above we rule that out. Knowing if we want to enable now or later is relevant
<dael> sanketj: I think priority stuff which is next issue is about how they stack relative to each other. This is to custom highlights. I think slightly tangential. I think there's somewhat separate problems
<dael> astearns: Prop: custom highlights will always go below native highlights
<dael> astearns: Obj?
<dael> RESOLVED: custom highlights will always go below native highlights