[css-backgrounds-4] Is the text value part of background-clip or not??

[jsnkuhn]

I proposed clean up of CSS background-clip for Interop 2024. It was rejected by the Interop group with some question as to whether the text value was or was "not on a standards track at the time of proposal selection."

web-platform-tests/interop#517 (comment)

So the direct question: Is the text value part of the spec or not?

It seems notable that with version 120 of Chrome (Dec 2023) finally removing the -webkit prefix that background-clip: text; is now supported across Chrome, Safari and Firefox (possibly not Edge yet?) with no prefix.

spec in question: https://drafts.csswg.org/css-backgrounds-4/#background-clip

[Loirooriol]

Well, it's in the Level 4 draft, as you linked. I guess you got that answer because of:

This spec is not yet ready for implementation. It exists in this repository to record the ideas and promote discussion

[Loirooriol]

Specifically, for W3C, the requirement is to be on Recommendation Track. So you would need a First Public Working Draft of Level 4.

[jsnkuhn]

Thanks for the explanation. This makes sense. I guess in my brain I'm still having trouble squaring the fact that this property that was initially introduced in 2008 could only be in a draft at this point. I certainly understand that full specs like Flexbox and Grid need 10 plus years to bake before they are ready but this doesn't seem like it's anywhere near that complicated. Maybe next year.

Also, I've posted in an Interop issue asking the group to use the link provided above to give folks a direct reference (instead of a generic link to w3.org) of what "Recommendation Track" actually means for future years.

web-platform-tests/interop#589 (comment)

[tabatkins]

Well, recall that this property value was introduced unilaterally by one browser, meant for internal usage but exposed to the wider web, without any spec whatsoever nor particular effort on the part of that browser's engineers to specify it. Sometimes that sort of thing still works out quickly when others do the legwork, but sometimes it falls thru the cracks. This is particularly the case when the feature itself is bad, as this one is. (The use-case is great, but the way this feature solves it is bad, as it fails inaccessibly - if the image doesn't load, you're left with unreadable transparent text.) The only reason we're specifying it at all is that it's used widely enough on the public web that browsers need to support it.

[bradkemper]

Maybe we need a conditional at-rule that only applies once an image is loaded (and automatically tries to pre-load it). Like maybe...

.example {
    color: red;
    @loaded url(/media/examples/leopard.jpg) {
        background-image: url(/media/examples/leopard.jpg);
        background-clip: text;
        color: transparent;
    }
}

[tabatkins]

What we need is support for the 'fill' property

[jsnkuhn]

FYI, I did also propose fill/stroke this year which was rejected as well: web-platform-tests/interop#440