[css-pseudo-4] Add a highlight pseudo-element for find-in-page or scroll-to-text

[chrishtr]

Right now you can customize the color of a selection highlight via ::selection, but there appears to
be nothing for user agent-specified selections such as find-in-page and scroll-to-text-fragment.

How about we add ::ua-selection ?

[chrishtr]

One possible concern would be a developer setting those colors to something with no contrast to the other text on the page, but I'm not sure if that is any worse than other things the developers could do to fight with the user or make mistakes regarding contrast.

If that is a significant concern, we could add normative language to require a certain amount of contrast with the background of the text, and if there isn't then allow UAs to ignore the color.

[chrishtr]

There is also the window.find API, which currently causes a selection highlight, not a find-in-page highlight.

[emilio]

In gecko the selection that find-in-page and window.find use is the same, we just paint it with a different style in the find-in-page case. Also there's another case which is the 'highlight-all' option, in which case we do use a different selection, but with yet another set of colors. So there are three cases here:

• Regular selection / regular color (window.find).
• Regular selection / find-in-page color (find-in-page primary match).
• Find-in-page selection.

In gecko the find-in-page color is called attention style (I think it's used also for a couple other things), fwiw.

This is somewhat similar to the discussions we've had about styling the inactive window selection, where it seemed that people preferred a pseudo-class that applied to the existing ::selection pseudo somehow rather than a whole new pseudo-element, but I could be misremembering.

[dbaron]

I'd previously suggested that CSS have a mechanism for multiple named selections and an API for creating them, and a find-in-page selection (or more than one of them) could fit in to that.

[emilio]

That seems somewhat related to this proposal by Microsoft.

[hober]

I've put this in the Thursday milestone so that @megangardner can attend.

[css-meeting-bot]

The CSS Working Group just discussed Highlight pseudo-element for find-in-page / scroll-to-text, and agreed to the following:

• RESOLVED: Megan replaces Tess as editor of Highlight API spec

The full IRC log of that discussion

<fantasai> Topic: Highlight pseudo-element for find-in-page / scroll-to-text
<Rossen_> github:https://github.com//issues/5233
<fantasai> florian: In Pseudos 4 we have ::selection, ::grammar-error, ::spelling-error
<fantasai> florian: Another thing ppl sometimes want to style is find-in-page highlight
<fantasai> florian: so maybe we want one of those
<fantasai> florian: I think I'd like to point out two things
<fantasai> florian: There is a work in progress spec to try to make it possible for authors to create custom highlights for any reason
<fantasai> florian: on the JS side of things, you'd set ranges on the page
<Rossen_> spec in reference is https://drafts.csswg.org/css-highlight-api-1/
<fantasai> florian: on CSS side you can style them
<fantasai> florian: If you want to style the browser one
<fantasai> florian: pointed out at least by Apple
<fantasai> florian: unlike the others, the UI that is used by some browsers
<fantasai> florian: isn't something you can create in CSS
<fantasai> florian: so expressing through selector, you can't express those effects in CSS
<tantek> curious about the visual effects that can't be expressed in CSS, screenshots?
<fantasai> florian: so proposed resolution is partially no change, and partially poke the editors of that spec
<fantasai> cbiesinger: scroll-to-text is that when searching for a thing and click search result, the browser will scroll to the first matching fragment
<fantasai> florian: idk if we want authors to have control over the UI
<fantasai> florian: or if want consistency across pages and should stay out of authors' hands
<tantek> this is also used by the IndieWeb for annotations and marginalia with fragmentions https://indieweb.org/fragmention
<tantek> q+
<Rossen_> ack tantek
<fantasai> tantek: 2 questions
<fantasai> tantek: find-in-page seems like a well-established feature
<fantasai> tantek: effects might not be consistent across browsers, could study and figure out what the effects are
<fantasai> tantek: curious about effects that can't be expressed in CSS
<fantasai> tantek: maybe add screenshots of the effect to the issue?
<fantasai> tantek: happy to defer decision until we have more info
<fantasai> tantek: don't seem to have a rush
<fantasai> tantek: on scroll-to-text or marginalia use case
<smfr> q+
<fantasai> tantek: in the Indie Web community, there's a diversity of how authors want to style this effect
<fantasai> tantek: both from perspective of person linking, and from perspective of site linking to the text
<fantasai> tantek: Sometimes author wants to say "these are the words I want to select"
<fantasai> tantek: and leave up to destination to highlight / style or not
<florian> q+
<fantasai> tantek: third case of browser doing something by default if neither author of link or author of page wants to do something
<fantasai> tantek: so complex interaction between author of the link, author of the page
<fantasai> tantek: maybe want to decide text fragment, or whole paragraph, or section, or something
<fantasai> tantek: and maybe browser does something
<fantasai> tantek: maybe need to investigate more
<fantasai> tantek: I see the utility for a page to control the presentation of highlights and annotations
<fantasai> tantek: but requires more study of possible effects to come up with a good solution
<florian> q?
<fantasai> tantek: Also sometimes animated
<fantasai> tantek: fragmention to a blog post of mine, my site will scroll to that paragraph, not to the text itself
<fantasai> tantek: and then do yellow highlight on that paragraph which then fades away
<fantasai> tantek: non-intrusive, here's what you are looking for
<fantasai> tantek: didn't want to pollute styling with something persistent
<fantasai> tantek: not sure that's possible with pseudo-element either
<fantasai> tantek: bunch of ways ppl doing presentation effects with this
<fantasai> tantek: so requires further documentation before designing a solution
<chrishtr> q+
<fantasai> smfr: I don't think the page can currently detect when the user does find in page
<fantasai> smfr: if we allow highlighting, then that exposes that information
<fantasai> smfr: so some privacy concerns there
<fantasai> smfr: not sure I want that to happen
<Rossen_> ack smfr
<Rossen_> ack fantasai
<Zakim> fantasai, you wanted to note :target allows anything, right? and to
<tantek> example link to the animation effect I was mentioning: https://tantek.com/2020/187/b1/changes-indieweb-organizing-indiewebcamp-west#keep%20listening (should work in any browser with JS turned on, Fragmentions implemented with a polyfill on my site)
<fantasai> fantasai: I don't think anything is exposed to the author
<fantasai> fantasai: highlight pseudos don't affect computed style or layout or anything except painting for the user
<tantek> scribenick: tantek
<fantasai> scribeNick: fantasai
<fantasai> smfr: Is there an API to detect?
<fantasai> florian: not yet determined
<Rossen_> ack florian
<fantasai> smfr: user after finding, can hit ? to select the result
<fantasai> florian: back to tantek's point wrt research
<fantasai> florian: one aspect not doable in CSS in general
<fantasai> florian: these pseudos are non-tree-abiding, and cannot affect layout
<fantasai> florian: so things that you can do in CSS in general, you can't do with these types of pseudo-elements
<fantasai> florian: so need to know what authors would want to do, if it's even possible
<fantasai> chrishtr: [asks for tantek to clarify]
<Rossen_> ack chrishtr
<fantasai> tantek: IndieWeb community is trying out different presentations of how to show fragmention when someone links to your site with a fragmention
<fantasai> tantek: yellow paragraph highlight + fade is just one example
<fantasai> tantek: others folks have used other effects
<fantasai> tantek: experimentation is happening on personal websites
<fantasai> tantek: e.g. "scroll that into view, show specific effect"
<fantasai> tantek: using polyfill right now
<fantasai> chrishtr: so writing JS code that parses the text in the URL?
<fantasai> tantek: I believe it's a fairly straightforward simple polyfill
<fantasai> tantek: which then adds class names that you can style
<fantasai> tantek: so that there's a separation between polyfill and provides a hook that author can style accordingly
<fantasai> tantek: not everyone has to write JS
<fantasai> chrishtr: main response to that is cool to be experimenting with this effect
<fantasai> chrishtr: ...
<fantasai> tantek: There are other interactions where select text in a blog post
<fantasai> tantek: you'd have options to then tweet that text, or do something else
<fantasai> tantek: multiple phases
<fantasai> tantek: method of causing a highlight to occurr
<fantasai> tantek: DOM hooks to style the highlight
<fantasai> tantek: independent of that you could potentially provide a UI to do something with the highlighted text
<fantasai> tantek: e.g. +1 the highlight, or copy and post to Twitter
<fantasai> Rossen_: sorry to interject, but I think we're straying
<fantasai> chrishtr: I agree with those use cases and would like to follow up offline
<fantasai> chrishtr: main point is, as long as we're making progress towards exploring this space so we can find the right APIs to expose that's good
<fantasai> chrishtr: Right now feature in one browsers that does not allow customization of the color
<tantek> looks like the fragmention polyfill I'm using puts a "fragmention" attribute on the containing paragraph (or possibly nearest block-level element)
<fantasai> chrishtr: and quite a lot of dev requests to change color in that particular UI mode
<fantasai> chrishtr: and want to respect that desire and make progress to authors customize look and feel
<fantasai> florian: The challenge here is that these are very restrictive pseudo-elements, only a few aspects of rendering can be change
<tantek> color (and background-color) are just the beginning of these needs, that's the point
<fantasai> florian: so need to see if what is desired is possible to solve via highlight pseudo
<tantek> we shouldn't prematurely optimizing for only color is my point
<tantek> s/prematurely/be prematurely
<fantasai> Rossen_: Somewhat related to highlight API spec
<hober> q+
<fantasai> hober: I'd like to step down as co-editor of highlight API, haven't had time
<fantasai> hober: I'd like to suggest as my replacement Megan Gardner
<fantasai> hober: she did the WebKit implementation
<fantasai> florian: I don't plan to step down, and I look forward to work with Megan
<fantasai> RESOLVED: Megan replaces Tess as editor of Highlight API spec
<fantasai> fantasai: think that find-in-page vs fragmention are slightly different in their needs
<Rossen_> ack hober
<Rossen_> ack fantasai
<tantek> +1 fantasai totally agreed the features are different
<fantasai> fantasai: so let's keep those things distinct in the discussion
<fantasai> Rossen_: +1
<fantasai> Rossen_: Ppl working on this need to figure out the boundaries between ? and ?
<fantasai> Rossen_: which exposes user interaction
<fantasai> Rossen_: if we are exposing something new, we are adding additional privacy-related exposure to the content layer
<fantasai> Rossen_: That is biggest sticking point, are we starting to expose something additional, and if so how so
<fantasai> Rossen_: outside of that, good thing to continue investigating