Re: [csswg-drafts] [css-highlight-api] position of the custom highlights relative to the built in ones (#4595)

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-highlight-api] position of the custom highlights relative to the built in ones<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/4595<br>
&lt;dael> smfr: css pseudo spec spec order highlights. selection is on top, then target text, spelling error, grammer error.  Where does ::highlight fit?<br>
&lt;astearns> s/smfr/sanketj<br>
&lt;dael> sanketj: Proposal is below the native ones. WOuldn't want author defined highlight to surpress<br>
&lt;florian> q+<br>
&lt;fantasai> wfm<br>
&lt;astearns> ack florian<br>
&lt;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<br>
&lt;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<br>
&lt;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<br>
&lt;dael> fantasai: Agree. I would note effects of highlights to stack so some effects will override but some will stack<br>
&lt;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<br>
&lt;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<br>
&lt;dael> astearns: Prop: custom highlights will always go below native highlights<br>
&lt;dael> astearns: Obj?<br>
&lt;dael> RESOLVED: custom highlights will always go below native highlights<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4595#issuecomment-805970263 using your GitHub account


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

Received on Wednesday, 24 March 2021 16:26:52 UTC