Hi folks,
I'm finally back to this. I just spent some time looking for further
sources of developer and user needs for this feature.
One use-case I had not previously appreciated is in user-facing
contrast adjustment for find-in-page results. With ::search-text an
extension could provide functionality to adjust the colors.
I've updated the chromestatus entry to add three more developer notes:
* On the original CSS WG issue someone wants this to avoid conflicts
with the ECMAScript spec highlights.
https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-1703272181
* In a discussion about find-in-page and accessibility, a "remaining
challenge is "Styling Search Matches"
https://schepp.dev/posts/rethinking-find-in-page-accessibility-making-hidden-text-work-for-everyone/#remaining-challenges
* A Mozilla user asks for the feature here:
https://connect.mozilla.org/t5/ideas/increased-visibility-for-current-quot-find-in-page-quot-match/idi-p/26500
WIth this in mind I will re-request API owners approval.
Cheers,
Stephen.
On Mon, Sep 29, 2025 at 2:10 PM Alex Russell
<[email protected]> wrote:
Hey Stepen,
Any progress? Again, inclined to LGTM, as the arguments we've
heard from other vendors to date are not compelling. If there's
more to add, would be great to get it in this thread. Would like
to get you unblocked.
Best,
Alex
On Monday, September 8, 2025 at 8:49:04 AM UTC-7 Stephen Chenney
wrote:
There's quite a bit of discussion going on in the TAG and I'm
(still) waiting on feedback from the client who requested this
as to their specific use case. My goal is to improve our
understanding of the motivation because right now it's unclear
how to balance the benefits vs the risks of the feature. I
have a meeting later this week to try to move things forward.
Sorry for the delay.
Cheers,
Stephen.
On Wed, Sep 3, 2025 at 10:09 AM Alex Russell
<[email protected]> wrote:
Any updates here?
I'm inclined to LGTM this, but would feel much better
about it if we had input from developers directly.
Best,
Alex
On Wednesday, August 27, 2025 at 11:07:10 PM UTC+1
[email protected] wrote:
Thanks Stephen for providing more context here. Please
do let us know if you're able to get more developer
feedback on this.
The way I'm looking at it, there's an important
distinction between possible reasons developers might
want the feature. If most only want it because the
color schemes of their sites happen to have poor
contrast with browsers' built-in find-in-page colors,
that's a sign that maybe browsers should take care of
ensuring contrast so developers don't have to think
about this a11y problem. On the other hand, if
developers want to control the find-in-page colors
because they want to make them fit in stylistically
with their page's color scheme, then that's clearly
demonstrating need for this feature.
Interestingly, selection color is kind of an example
in both directions. If devs don't do anything with it,
browsers ensure contrast automatically, but authors
can still control the colors if they want.
-- Dan
On Friday, August 15, 2025 at 5:45:19 AM UTC-7 Stephen
Chenney wrote:
Sorry for the time out. I'm still waiting for
feedback from the developers who requested this,
but I'll try to add some responses now.
On Wed, Jul 23, 2025 at 12:05 PM 'Dan Clark' via
blink-dev <[email protected]> wrote:
The API Owners discussed this today and had
some concerns that the motivation is not as
clear as it could be. We'd like to better
understand the developer need for styling
these highlights.
We have TAG review now,
https://github.com/w3ctag/design-reviews/issues/1120,
and the use case seems strong to them. They had
questions about Safari compat.
Looking at the Motivation section
<https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md#-motivation>
of
the explainer, 3 StackOverflow links were given:
* Someone directly asks for CSS styling of
find-in-page
<https://stackoverflow.com/questions/50309703/css-for-browsers-find-in-page>:
the use case is /"if a user use's their
browser's find function to search through
the table, the browser will highlight the
matching text, but I want to be able to
highlight the entire row if any of it's
cells contain a match". /But this proposal
won't solve for this; it only allows for
things like the color/background color to
be changed, not the area that the
highlight covers.
* Another direct question
<https://stackoverflow.com/questions/18666075/how-to-style-detect-highlighted-boxes-generated-from-browser-native-search-in-pa>:
it's not clear why the developer wants to
do this.
* A user wants to hide find-in-page results
<https://stackoverflow.com/questions/77458310/confuse-browsers-in-built-find-in-page-feature>:
for this one the developer basically wants
to disable find-on-page, which seems like
something we don't want to be helping with
since it makes things less accessible for
users.
Yes, we don't know why the 2nd link wants
styling. Regarding the last, developers can
already capture the Ctrl-F and disable find in
page, and as far as I can tell the way to get
custom search styling is to implement the entire
find-in-page system yourself. That's not a
developer friendly solution.
So these don't make a strong case to why this
feature is the right answer.
If the main developer concern being solved for
is lack of contrast for find results against
other page content, such as in
https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-1703272181,
then couldn't browsers be doing a better job
of solving this problem by default rather than
pushing the burden onto developers? For
example, the case pointed out in that issue
comment
<https://github.com/w3c/csswg-drafts/issues/3812#issuecomment-1703272181>
is not so bad in Safari because of Safari's
greying-out of the rest of the page when Find
is active.
Our request comes from an embedder. They can apply
downstream patches themselves to adjust styling,
but it is cumbersome and gets more complicated
when different styling is needed for different
elements. Then they are implementing this entire
feature themselves. The embedder story would get
more complex, I think, if the browser layer took
over find-in-page, as Safari seems to do. It's
also worth pointing out that a browser level
solution takes away power from the site. If an
author doesn't like what Safari is doing, they
cannot do anything about it beyond a complete
custom search function. This raises the difficulty
for those just wishing to improve the search
results styling on their page.
I'll reply some more once I get more feedback from
developers.
Stephen.
-- Dan
On Wednesday, July 16, 2025 at 12:41:48 PM
UTC-7 Stephen Chenney wrote:
There's no problem waiting. We're not in
any big hurry and we slowed ourselves down
anyway.
Regarding WPT testing there's already
https://github.com/web-platform-tests/wpt/issues/45844
to get this done and we should solve the
spelling/grammar issue too,
https://github.com/web-platform-tests/wpt/issues/30863.
I'll ask around and see if anyone at
Igalia has bandwidth to do this.
Cheers,
Stephen.
On Wed, Jul 16, 2025 at 11:14 AM Philip
Jägenstedt <[email protected]> wrote:
On testing in WPT, can you look into a
WebDriver BiDi command for triggering
find-in-page? That would enable
testing this.
On Wed, Jul 16, 2025 at 5:11 PM Philip
Jägenstedt <[email protected]> wrote:
Thank you for filing
https://github.com/w3ctag/design-reviews/issues/1120!
Since it was just two days ago,
let's give it some time before
proceeding. +Jeffrey Yasskin if
the TAG can expedite this, it
would be great :)
On Mon, Jul 14, 2025 at 1:43 PM
Stephen Chenney
<[email protected]> wrote:
On Sun, Jul 13, 2025 at
11:58 PM Domenic Denicola
<[email protected]> wrote:
On Thursday, July 10, 2025
at 4:41:12 AM UTC+9
Chromestatus wrote:
Contact emails
[email protected],
[email protected]
Explainer
https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md
<https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md>
Specification
https://drafts.csswg.org/css-pseudo-4/#selectordef-search-text
<https://drafts.csswg.org/css-pseudo-4/#selectordef-search-text>
Design docs
https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md
<https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md>
Summary
Exposes find-in-page
search result styling
to authors as a
highlight
pseudo-element, like
selection and spelling
errors. This allows
authors to change the
foreground and
background colors or
add text decorations,
which can be
especially useful if
the UA defaults have
insufficient contrast
with the page colors
or are otherwise
unsuitable.
Blink component
Blink>CSS
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22>
Search tags search
<http:///features#tags:search>
TAG review None
TAG review status Not
applicable
Can you explain why it is
not applicable? I can't
see which exception
<https://www.chromium.org/blink/launching-features/wide-review/#exceptions>
category it might fall into.
We weren't sure because this
is a feature already in the
CSS spec. I'll set up a review
now, and I'll also look into
the reviews for all the other
highlights (spelling. grammar,
find-in-page etc) to see if
there's anything still
actionable there.
Risks
Interoperability and
Compatibility
The feature is in the
CSS Pseudo spec and
there are no open
issues. The behavior
is designed to be
implementable in
Firefox and Chrome,
but is unlikely to be
viable in Safari due
to highly customize UI
for find-in-page. The
spec is explicit that
browsers may choose
not to implement this
feature provided
@supports information
is correct. The Safari
behavior is so
different that
developers are
unlikely to believe
their styling would
apply there.
/Gecko/: Under
consideration
(https://github.com/mozilla/standards-positions/issues/1103
<https://github.com/mozilla/standards-positions/issues/1103>)
/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/421
<https://github.com/WebKit/standards-positions/issues/421>)
Will file a request
for position, but in
spec conversations
were neutral with no
expectation of
implementing it
themselves.
/Web developers/:
Positive Developers
wishing to avoid
conflicts with the
find-in-page colors
and their page styles
have requested this
feature. Someone
directly asks for CSS
styling of
find-in-page:https://stackoverflow.com/questions/50309703/css-for-browsers-find-in-page
<https://stackoverflow.com/questions/50309703/css-for-browsers-find-in-page>
Another direct
question:
https://stackoverflow.com/questions/18666075/how-to-style-detect-highlighted-boxes-generated-from-browser-native-search-in-pa
<https://stackoverflow.com/questions/18666075/how-to-style-detect-highlighted-boxes-generated-from-browser-native-search-in-pa>
A developer wants to
hide find-in-page
results:
https://stackoverflow.com/questions/77458310/confuse-browsers-in-built-find-in-page-feature
<https://stackoverflow.com/questions/77458310/confuse-browsers-in-built-find-in-page-feature>)
and could do so by
styling them as
transparent
/Other signals/:
Ergonomics
None.
Activation
There is no way to
polyfill this. There
is no real challenge
to adopting beyond
awareness that the
feature exists, and we
will be producing blog
postings and other
social media
evangelization.
Security
There is no security
risk. The CSS styling
is available
regardless of whether
the text is search for
or not, so user
find-in-page queries
cannot be seen by script.
WebView application risks
Does this intent
deprecate or change
behavior of existing
APIs, such that it has
potentially high risk
for Android
WebView-based
applications?
No
Debuggability
There is no security
risk. The CSS styling
is available
regardless of whether
the text is search for
or not, so user
find-in-page queries
cannot be seen by script.
Will this feature be
supported on all six
Blink platforms
(Windows, Mac, Linux,
ChromeOS, Android, and
Android WebView)? Yes
All platforms support
find-in-page and could
use CSS styling to
improve legibility on
some sites.
Is this feature fully
tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
No
Testing is in
wpt_internal tests due
to a lack of wpt
support for adding
find-in-page markers.
third_party/blink/web_tests/wpt_internal/css/css-pseudo/search-text-*
DevTrial instructions
https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md
<https://github.com/Igalia/explainers/blob/main/css/find-in-page/README.md>
Flag name on
about://flags
Experimental Web
Platform Features
Finch feature name
SearchTextHighlightPseudo
Rollout plan Will ship
enabled for all users
Requires code in
//chrome? False
Tracking bug
https://issues.chromium.org/issues/339298411
<https://issues.chromium.org/issues/339298411>
Measurement We will
implement UseCounters
for this pseudo
element (and all the
other too, see
https://issues.chromium.org/issues/381093928
<https://issues.chromium.org/issues/381093928>)
Availability
expectation Available
in Chrome, and
Firefox. Not available
in Safari
Adoption expectation
Hard to predict and
not relevant to most
sites
Adoption plan Blog
posts and developer
outreach
Non-OSS dependencies
Does the feature
depend on any code or
APIs outside the
Chromium open source
repository and its
open-source
dependencies to function?
No
Estimated milestones
Shipping on desktop
140 DevTrial on
desktop 135 Shipping
on Android 140
DevTrial on Android
135 Shipping on
WebView 140
Anticipated spec changes
Open questions about a
feature may be a
source of future web
compat or interop
issues. Please list
open issues (e.g.
links to known github
issues in the project
for the feature
specification) whose
resolution may
introduce web
compat/interop risk
(e.g., changing to
naming or structure of
the API in a
non-backward-compatible
way).
None
Link to entry on the
Chrome Platform Status
https://chromestatus.com/feature/5195073796177920?gate=5047118541881344
<https://chromestatus.com/feature/5195073796177920?gate=5047118541881344>
Links to previous
Intent discussions
Intent to Prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c447ed4dfd05b588e2afc650277371fd%40igalia.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c447ed4dfd05b588e2afc650277371fd%40igalia.com>
This intent message
was generated by
Chrome Platform Status
<https://chromestatus.com>.
--
You received this message
because you are subscribed to
the Google Groups "blink-dev"
group.
To unsubscribe from this group
and stop receiving emails from
it, send an email to
[email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzRDTpo0grPCaqQkdUOacQQ0ovjr_mL-%3DpOmxYKqcyNYMw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzRDTpo0grPCaqQkdUOacQQ0ovjr_mL-%3DpOmxYKqcyNYMw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are
subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop
receiving emails from it, send an email to
[email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/df61d4d1-f902-46ef-9e6d-ad349f7c556bn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/df61d4d1-f902-46ef-9e6d-ad349f7c556bn%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzT8TPf8dPQXzSUM_ueX%2B1wvhHFfo%2B6fv2cPtUaydeNJwg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzT8TPf8dPQXzSUM_ueX%2B1wvhHFfo%2B6fv2cPtUaydeNJwg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
