Styling ::search-text and Different Spotlight-y Pseudo-Parts

Chrome 144 just lately shipped ::search-text, which is now considered one 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 examine them, which is precisely what I’m going to do right here right this moment, because it’s not tremendous apparent what they do based mostly on the title of the pseudo-element. I’ll additionally clarify why we’re capable of customise them, and counsel how.

The various kinds of spotlight pseudo-elements

And let’s not overlook concerning the <mark> HTML factor 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 (moreover ::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 need to change that.

I’m certain there are numerous methods to resolve this (I need to hear “problem accepted” within the feedback), however the perfect answer that I’ve give you makes use of relative coloration syntax. I took incorrect turns with each background-clip: textual content and backdrop-filter: invert(1) earlier than realizing that many CSS properties are off-limits in relation 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 won’t assist that but, so right here’s a video that exhibits how the highlighted textual content adapts to background coloration modifications.

What’s taking place 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, making certain that it stands out it doesn’t matter what, and due to the brand new CodePen slideVars, you possibly can fiddle with the demo to see this in motion. You would possibly have the ability to do that with coloration codecs moreover 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 identical 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 could have accessible distinction, it appears as if they are going to more often than not (it’s best to at all times verify coloration distinction utilizing coloration distinction instruments, regardless).

In case you don’t just like the randomness of inverting colours, that’s comprehensible. You’ll be able to completely choose colours and write conditional CSS for them manually as a substitute, 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. Moreover, I feel sure UI components (e.g., highlights, errors, focus indicators) ought to be ugly. They ought to stand out in a brutalist form of approach 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 in addition in case two differing kinds overlap one another (e.g., the person selects textual content presently 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 a substitute 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), in addition they mix into one another in order that we are able to 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 (crimson underlines and inexperienced underlines respectively, sometimes contrasted towards the impartial background of an editable factor reminiscent of <textarea>).

However mark, ::choice, ::target-text, and new-to-Chrome ::search-text? Effectively, they will seem anyplace (even on prime of one another), so I feel it’s essential that they’re visually distinctive from one another whereas being accessible always. Once more although, even fully-inverted colours may be inaccessible. Actually, the inverse of #808080 is #808080, so take a look at, take a look at, take a look at! Though, perhaps contrast-color() might come to the rescue as soon as the CSS Coloration Module Stage 5 model of it ships.

Within the meantime, please, no extra highlight-y components!