[css-pseudo-4] single highlight pseudo for find-in-page?

[delan]

1. Do we really need two highlight pseudos, or would a pseudo-class like ::search-match:active make more sense? Since ::active-search and ::inactive-search sound like they would be mutually exclusive, this may just be a question of elegance, not ambiguity like in [css-pseudo-4] ::selection vs ::inactive-selection #4579.

#3812 suggests adding two new highlight pseudos, ::active-search and ::inactive-search, for find-in-page search results. But these highlights are mutually exclusive, so they need not be two separate pseudo-elements and highlight overlays.

We propose instead adding a single highlight pseudo with a pseudo-class (selectors #pseudo-element-states), such as ::search-text:active. You would select ::search-text for all matches, ::search-text:active for the active match, or ::search-text:not(:active) for the other matches.

The exact naming is not critical, but ::search-text would be by analogy with ::target-text, and clearly describes the thing being highlighted (like ::spelling-error), more so than alternatives like ::search-match or ::find-in-page.

[smfr]

I'm not really sure that having Find pseudos is going to work very well.

The current behavior in Safari is that when you do a Find and there are results, the current result is selected (using normal DOM selection), and the UA draws an overlay where the current find result gets a yellow bubble (which entirely obscures whatever the page renders). If the user dismisses the Find overlay, then the result remains selected, so that it can be copied, for example.

Now if the page author styles ::search-text, the results are surprising. First, that style won't be visible in UAs that provide their own Find overlay, and second, when the Find overlay is dismissed, does the found word get both selection, and ::search-text applied? Or does ::search-text go away when the Find operation is canceled?

[schenney-chromium]

I expect that in Safari the find-in-page pseudo will be ignored. I would expect it to only apply when a search is active, but there the browser has a specialized UI, and it would disappear when the selection takes over in Safari. The only alternative I can think of would be to disable the overlay interface and use Chromium/Gecko behavior when a find-in-page pseudo is present, but I certainly wouldn't advocate for that as good for users.

Firefox also has a search highlight color that switches to selection, and I would expect the pseudo that is used to switch also from find-in-page to selection.

This suggest the spec should use the appropriate "... browsers may ..." language.

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo-4] single highlight pseudo for find-in-page?, and agreed to the following:

• RESOLVED: Add ::search-text, using :current to distinguish currently-focused match, mark as optional to implement

The full IRC log of that discussion

florian: We have this set of highlight pseudo-elements that lets you restyle how UA styles spelling-error, selection, etc.
florian: as part of that family, being able to restyle browser's find-in-page has been proposed
florian: also discussed whether to highlight active vs inactive
florian: the underlying question, does that even work? E.g. in Safari, wouldn't restyle how browser does it already
florian: Safari does it as an overlay
florian: we would need some way to say not to do the overlay, or accept double-styling, or ...
florian: So what pseudo-classes do we need, and how do we do it?
schenney: Issues on agenda due to trying to prototype
schenney: in Chromium
schenney: both Firefox and Safari convert the matched text to ::selection when the UI for find-in-page is exited
schenney: I don't think that's a problem, but we may need to define what happens there
schenney: If people think this is a horrible idea, should say so. So first, any objections to prototyping?
florian: no objection to prototyping, but should have some idea of how it should work in e.g. Safari
florian: doesn't mean don't do it, but know what it means
schenney: ... I don't think Safari has reasonable path to implementing
florian: one approach is Safari doesn't implement the syntax
florian: but also part of defining is defining painting order
florian: is this an area where we can pick an answer, or will browsers need different answers
florian: Unlike other pseudos, where we seem to have agreement on what we do in the page, there's more variation here
florian: could come up with an answer, and ask Safari people to answer in question
Rossen: fallback is?
florian: you try to style something and it doesn't get styled
q+
smfr's comment btw: https://github.com//issues/10212#issuecomment-2086545393
Rossen: seems we have one UA that unlikely to implement in forseeable future if ever
q-
Rossen: maybe loose language in terms of "may" rather than "must"
Rossen: and safe fallback
florian: We should specify the feature in terms of "must" as in "if you support the feature, do it this way, but it's optional to support the feature"
florian: otherwise hard for authors to know how to do the styling, if allowed to do it in multiple ways
schenney: back to issue, what do we name this pseudo-element?
schenney: proposal is to name it ::search-text, consistent with ::target-text
schenney: and then to add :active pseudo-class to style active vs inactive differently
florian: this seems reasonable to me
florian: active vs inactive is if multiple words highlighted, and one is currently focused?
florian: this is a UI feature, not required to highlight multiple
florian: if highlighting several, one is active and others inactive; if highlighting multiple, then what?
schenney: in that case it's active
schenney: we can't expose what the browser's doing due to privacy concerns
ack kbabbitt
q+
ack khush
ack fantasai
fantasai: :active currently is about click state in most cases, not about activation (though I wish it was)
scribe+ TabAtkins
fantasai: are we OK with this not being about click state for ::search-text?
fantasai: also, is it :active or is it :focus?
schenney: It's active in that it will be converted to selection when exiting search UI
schenney: but using new class name not used anywhere else
schenney: focus could maybe work
Rossen: I would stay away from :focus for accessibility reasons
+1 to staying away from focus for accessibility reasons
Rossen: :active is less problematic
Rossen: also assumes it's a singleton, not sure if this is true today
fantasai: "current" could work - we do have a :current pseudo
https://www.w3.org/TR/selectors-4/#time-pseudos
florian: what's it for?
fantasai: time-dimensional pseudoclasses
florian: If it doesn't conflict, reusing might be okay
florian: it's somewhat comparable
florian: there's a sort of time axis, but only wrt prev/next buttons
q?
q+
florian: wrt one thing highlighted, that's an existing feature; but I don't think it's a problem
florian: there's a whole range of colors depending on window highlighted or not or one or many etc.
ack florian
florian: I'm not sure it's doing anything not represented by the pseudos we're discussing
florian: but it's not just theoretical
vmpstr: Discussed Safari might not be able to implement, but if they did, changing color with backdrop change could affect things
florian: I don't think Safari is dimming the backdrop, it's applying a whole-page effect
florian: that's not representable by CSS on a highlight pseudo
florian: if we expect other browsers to do this, maybe it's the wrong approach
q+
ack vmpstr
ack smfr
smfr: Unsure of reason to add new pseudos. Browser do different things, e.g. Safari does an overlay with punching hole through it for the result
smfr: justification to add new pseudos seems pretty weak
florian: There are some browsers that render this as something representable as in-page CSS
florian: author could restyle
s/could/could reasonably/
florian: but in other UAs could decide to not implement
schenney: the use case was pages that do e.g. code display/editing
schenney: being able to differentiate in-page search vs browser search
schenney: another use case was someone who didn't want people to cheat in their browser game by using in-page search, so could make invisible
fantasai: actually that was my concern, that pages would abuse to make find-in-page unusable. E.g. heavily advertised content that wants you to read through rather than find the thing you're looking for
smfr: [missed]
Rossen: Fragment navigation or whatever ...
smfr: scroll-to-text-fragment
Rossen: that gets navigated to, as far as I know it's the same mechanism
Rossen: not sure if UX is different?
schenney: in Chromium, the underlying rendering implementation would be the same
s/[missed]/like those annoying web pages that turn off context menus…]
schenney: shared system for painting, different frameworks for identifying the text
schenney: anti-pattern case is a good one
florian: 1. Do we do this? 2. If so, how?
florian: I haven't heard any arguments about the proposed syntax being wrong, but debate over whether to do it
florian: possibly we want to introduce some browser failsafe, like if contrast is bad can ignore autho styling
s/autho/author/
florian: if we have this feature, the proposed syntax is reasonable
POLL: Should we have this feature?
Rossen: Any objections to adopting this feature?
smfr: Not going to object, just neutral. Safari may not implement.
I think it may be a minefield we’ll need to remove, but I won’t object
schenney: so we will call it ::search-text, and you may use ..? :current?
schenney: to distinguish which is the current focused one
smfr: wrt naming, thinking back to content-visiblity: hidden-find-matchable-thingy
smfr: doesn't that use the term 'find' and not 'search'?
vmpstr: That term does not appear in syntax, only in the spec
smfr: ok
PROPOSED: Add ::search-text, using :current to distinguish currently-focused match, mark as optional to implement
RESOLVED: Add ::search-text, using :current to distinguish currently-focused match, mark as optional to implement