Text fragments are a feature that encodes a textual query into the document into the URL. When loading a page, the browser scrolls to the text that matches the query and highlights it.

This issue is a breakout from issue #5233 to consider adding a pseudo-element for this use case. The specific proposal is to add a pseudo-element called ::text-fragment-match that allows the developer to style the match's color, background, and a few more properties. The exact list and matching mechanism would be the same as for ::selection, ::spelling-error, etc. The same considerations would come into play for this highlight as for the other ones, such as integration with various browser modes like forced colors and dark mode.

Text fragments are currently implemented in Chromium browsers. For concrete reference existing UI works as follows:

1. Page loads and renders
2. Page scrolls to the fragment match, and highlights it with a background color that is the same as the Chromium find-in-page UA feature's non-active match (*) color (currently yellow). If that find-in-page color changes in different modes of the browser, the fragment match color should also already be changing to match it
3. The highlight is removed instantly if the user taps or clicks on the page. There is no animation
   (example link)

(*) Chromium find-in-page has two highlight colors: the active match and the non-active match. If there are multiple matches to the user's find-in-page query, then one of them is considered active at a time, and the user can use the mouse or keyboard to iterate between them.

In earlier CSSWG discussion, we concluded:

1. The WG is interested in adding a feature to allow customizations of such highlights
2. Text fragments seems a simpler situation than find-in-page, since find-in-page UIs vary widely across browsers

There were also questions raised about whether there are animations or other complexities in browser UIs to take into account (answer: currently no for Chromium). It may also be likely that the current UI of Chromium sticks long-term, because the highlight is an externally injected UI that is not provided by the page itself, and therefore the browser must use a UI that is most compatible with existing site behaviors (spell check underlines also have a simple, non-intrusive UI affordance, presumably for a similar reason). A simple highlight meets that criterion.

@frivoal (and others) WDYT? Based on the above do you think there are other considerations to take into account for the specific case of basic text-fragment highlighting?