Chrome 144 lately shipped ::search-text, which is now one in every of a number of highlight-related pseudo-elements. This one selects find-in-page textual content, which is the textual content that will get highlighted if you do a Ctrl/Command + F-type seek for one thing on a web page and matches are discovered.
By default, ::search-text matches are yellow whereas the present goal (::search-text:present) is orange, however ::search-text permits us to alter that.
I’ll admit, I hadn’t actually been following these spotlight pseudo-elements. Up till now, I didn’t even know that there was a reputation for them, however I’m glad there may be as a result of that makes it simpler to spherical all of them up and evaluate them, which is precisely what I’m going to do right here at this time, because it’s not tremendous apparent what they do primarily based on the title of the pseudo-element. I’ll additionally clarify why we’re capable of customise them, and recommend how.
The various kinds of spotlight pseudo-elements
| Pseudo-selector | Selects… | Notes |
|---|---|---|
::search-text |
Discover-in-page matches | ::search-text:present selects the present goal |
::target-text |
Textual content fragments | Textual content fragments enable for programmatic highlighting utilizing URL parameters. In case you’re referred to a web site by a search engine, it would use textual content fragments, which is why ::target-text is well confused with ::search-text. |
::choice |
Textual content highlighted utilizing the pointer | |
::spotlight() |
Customized highlights as outlined by JavaScript’s Customized Spotlight API | |
::spelling-error |
Incorrectly spelled phrases | Just about applies to editable content material solely |
::grammar-error |
Incorrect grammar | Just about applies to editable content material solely |
And let’s not overlook concerning the HTML aspect both, which is what I’m utilizing within the demos under.
What ought to spotlight pseudo-elements appear to be?
The query is, if all of them (in addition to ::spotlight()) have default styling, why would we have to choose them with pseudo-elements? The reason being accessibility (coloration distinction, particularly) and value (emphasis). For instance, if the default yellow background of ::search-text doesn’t distinction nicely sufficient with the textual content coloration, or if it doesn’t stand out towards the background of the container, then you definately’ll wish to change that.
I’m certain there are numerous methods to unravel this (I wish to hear “problem accepted” within the feedback), however the very best answer that I’ve give you makes use of relative coloration syntax. I took improper turns with each background-clip: textual content and backdrop-filter: invert(1) earlier than realizing that many CSS properties are off-limits relating to spotlight pseudo-elements:
physique {
--background: #38003c;
background: var(--background);
mark,
::choice,
::target-text,
::search-text {
/* Match coloration to background */
coloration: var(--background);
/* Convert to RGB then subtract channel worth from channel most (255) */
background: rgb(from var(--background) calc(255 - r) calc(255 - g) calc(255 - b));
}
}Your browser may not assist that but, so right here’s a video that exhibits how the highlighted textual content adapts to background coloration modifications.
What’s occurring right here is that I’m changing the container’s background coloration to RGB format after which subtracting the worth of every channel (r, g, and b) from the utmost channel worth of 255, inverting every channel and the general coloration. This coloration is then set because the background coloration of the highlighting, guaranteeing that it stands out it doesn’t matter what, and because of the brand new CodePen slideVars, you possibly can fiddle with the demo to see this in motion. You would possibly be capable of do that with coloration codecs in addition to RGB, however RGB is the best.
In order that covers the usability, however what concerning the accessibility?
Effectively, the highlighting’s textual content coloration is similar because the container’s background coloration as a result of we all know that it’s the inverse of the highlighting’s background coloration. Whereas this doesn’t imply that the 2 colours may have accessible distinction, it appears as if they may more often than not (it is best to all the time examine coloration distinction utilizing coloration distinction instruments, regardless).
In case you don’t just like the randomness of inverting colours, that’s comprehensible. You may completely decide colours and write conditional CSS for them manually as an alternative, however discovering accessible colours that stand out towards the totally different backdrops of your design for the entire various kinds of spotlight pseudo-elements, whereas accounting for various viewing modes reminiscent of darkish mode, is a headache. In addition to, I feel sure UI parts (e.g., highlights, errors, focus indicators) ought to be ugly. They ought to stand out in a brutalist form of means and really feel disconnected from the design’s coloration palette. They need to demand most consideration by deliberately not becoming in.
Needless to say the various kinds of spotlight pseudo-elements needs to be visually distinctive too, for apparent causes, but additionally in case two differing kinds overlap one another (e.g., the person selects textual content at present matched by find-in-page). Due to this fact, within the amended code snippet under, mark, ::choice, ::target-text, and ::search-text all have barely totally different backgrounds.
I’ve left mark unchanged, the r worth of ::choice because it was, the g worth of ::target-text because it was, and the b worth of ::search-text because it was, so these final three solely have two channels inverted as an alternative of all three. They’re diverse in coloration now (however nonetheless look inverted), and with the addition of an alpha worth at 70% (100% for ::search-text:present), additionally they mix into one another in order that we will see the place every spotlight begins and ends:
physique {
--background: #38003c;
background: var(--background);
mark,
::choice,
::target-text,
::search-text {
coloration: var(--background);
}
mark {
/* Invert all channels */
background: rgb(from var(--background) calc(255 - r) calc(255 - g) calc(255 - b) / 70%);
}
::choice {
/* Invert all channels however R */
background: rgb(from var(--background) r calc(255 - g) calc(255 - b) / 70%);
}
::target-text {
/* Invert all channels however G */
background: rgb(from var(--background) calc(255 - r) g calc(255 - b) / 70%);
}
::search-text {
/* Invert all channels however B */
background: rgb(from var(--background) calc(255 - r) calc(255 - g) b / 70%);
&:present {
/* Invert all channels however B, however with out transparency */
background: rgb(from var(--background) calc(255 - r) calc(255 - g) b / 100%);
}
}
}::spelling-error and ::grammar-error are excluded from all this as a result of they’ve their very own visible affordances (pink underlines and inexperienced underlines respectively, sometimes contrasted towards the impartial background of an editable aspect reminiscent of ).
However mark, ::choice, ::target-text, and new-to-Chrome ::search-text? Effectively, they’ll seem anyplace (even on high of one another), so I feel it’s necessary that they’re visually distinctive from one another whereas being accessible always. Once more although, even fully-inverted colours might be inaccessible. In reality, the inverse of #808080 is #808080, so check, check, check! Though, perhaps contrast-color() may come to the rescue as soon as the CSS Colour Module Degree 5 model of it ships.
Within the meantime, please, no extra highlight-y parts!
