background-clip: text

[thebabydino]

Description

This is now supported unprefixed and in the shorthand in all browsers, but bugs still remain.

Most notable ones, both related to multiple background layers:

• Firefox 🪲 1481498 - if one background-clip value is text, but not all of them are, the result is incorrect.
• Safari 🪲 267129 - if we have at least one background layer clipped to text, this breaks background-blend-mode

The majority of my most common uses for background-clip: text involve blending two background layers out of which only one is clipped to text.

So I most commonly have to resort to an absolutely positioned pseudo-element covering its parent. The pseudo then gets blended with its parent's text content.

This can be problematic for inline elements like links. Let's say we want an on :hover/ :focus XOR effect created with the difference blend mode. All is fine if the link doesn't wrap.

:hover case scenario

But if the link wraps, we have a problem.

the problem with multi-line links

To get around this, I have to make the link inline-block. Which also breaks when the link is wider than is container. To also avoid that problem, I need to wrap the link text inside a span which I then blend with the actual link. Which works, but isn't ideal.

Specification

CSS Backgrounds and Borders Module Level 3

Additional Signals

No response

[gsnedders]

https://wpt.fyi/results/css/css-backgrounds?label=master&label=experimental&aligned&q=clip is probably a decent starting point

[jsnkuhn]

The new/experimental background-clip value of border-area included in some of these tests seems to make this less likely to get accepted.

[jsnkuhn]

Metrics from Chrome Status:

background-clip is used on 37% of page loads. This is much higher than I expected. https://chromestatus.com/metrics/css/timeline/popularity/23

-webkit-background-clip is around 8% https://chromestatus.com/metrics/css/timeline/popularity/178

not sure if there's a way to get specific numbers for the text value

[progers]

The new/experimental background-clip value of border-area included in some of these tests seems to make this less likely to get accepted.

@jsnkuhn , can you help me understand this? I think this proposal is just about background-clip: text, and would exclude border-area (https://github.com/web-platform-tests/interop/issues/881)?

[jsnkuhn]

This is specifically regarding the the lack of existing tests for multiple background-clip values that don't include border-area.

This sort of case as mentioned in the Firefox bug from the OP:

background-image: linear-gradient(), linear-gradient();
background-clip: text, border-box

In this case one of the gradients would be being used as a "text fill" and the other as an actual background-image. There is, as far as i can tell, no test for this. But there exists a similar test for multiple backgrounds/clips that included border-area:

https://wpt.fyi/results/css/css-backgrounds/background-clip/clip-border-area-multiple-backgrounds.html?label=master&label=experimental&aligned&q=background-clip

So something similar without the border-area would probably need to be created to cover this?

A similar issue exists with a lack of tests for a background-image: none to add a separate background-clip values for an image and the background-color.

background-color: red;
background-image: linear-gradient(), none;
background-clip: text, border-box

Here again the gradient is applied as a text fill and the image value of none is needed to include a clipping value for the background-color

[noamr]

The failing WPTs reveal that this issue in fact needs a lot of spec work, see https://github.com/w3c/csswg-drafts/issues/9563

[wpt-interop]

Thank you for proposing background-clip: text for inclusion in Interop 2025.

We wanted to let you know that this proposal was not selected to be part of Interop this year.

On behalf of the entire Interop team, thank you for submitting this proposal for consideration. We got many more proposals than we could include in this year's project, necessitating some difficult choices. Please note this should not be taken as a comment on the technology as a whole, or our willingness to consider it for Interop in the future. We appreciate the work you put into your proposal, and would welcome your participation in future rounds of Interop.

For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2025.

Posted on behalf of the Interop team.