The ancient Safari blog post that I mentioned (which relies on "-webkit-background-clip:border" being valid) is https://webkit.org/blog/164/background-clip-text/

(The demo there is focusing on "-webkit-background-clip: text", which is moving towards standardization & which is implemented in Firefox Nightly & Edge 13. But I'm focusing on the part where it also relies on the "border" value as the second entry in a list -- specifically, it has "-webkit-background-clip: text, border;")

For reference, I also filed https://bugs.webkit.org/show_bug.cgi?id=156641 on this bug for WebKit, and I initially filed https://bugzilla.mozilla.org/show_bug.cgi?id=1265071 on this CSS being rejected in Firefox before I realized that Firefox was likely-correct.)

I'm not sure about this property specifically, but since it's an old -webkit prefixed one, its behaviour is calcified as-is, pre-standardisation.

chromestatus.com currently shows 15% of page loads contain -webkit-background-clip (https://www.chromestatus.com/metrics/css/timeline/popularity/178 - really high!). We don't have information about the usage of non'-box'-suffixed values, but without this data it's too risky to change behaviour.

This is one we're likely stuck with.

+tabatkins in case he's got more insight into this one.

We should probably add a counter. The prefixed property also supports a "text" value.

FWIW, I've been trying to keep track of our various legacy behaviors we have (with the intent that we can slowly make it smaller). https://docs.google.com/document/d/18PQf6HIrQPh8kKp3yNRZoeijBP4mF-7yZsmdoGT23gg/

In general, it would also be interesting to have counters of 'how often does a webkit prefixed property get overridden by the non-prefixed version'.

> since it's an old -webkit prefixed one, its behaviour is
> calcified as-is, pre-standardisation.

Prefixed properties don't necessarily *have* to be calcified.  If the modern syntax evolves and not much web content depends on the legacy syntax being different, then it's completely reasonable to evolve the legacy version in tandem.  (And unless there's proof that the web depends on the legacy cruft, it seems like it's better to err on the side of keeping the legacy version consistent with the unprefixed version.)

So: in this bug, I'm curious if there's any proof that legacy content *does* depend on these old suffixless "box" values (content/padding/border) for -webkit-background-clip.

(Let's set "text" aside -- Microsoft and Mozilla have both found that the web depends on "-webkit-background-clip: text", which is an unfortunate reality.)

If it *is* the case that the web depends on these specific suffixless "box" values, it would be great to see evidence of that, and then Mozilla and Microsoft may need to implement them (as "-webkit-background-clip" values) for compatibility's sake.  But otherwise, it would be great to see Blink remove them, for compatibility's sake (and for a reduced legacy-code-maintenance burden).

tl;dr: +1 to "we should probably add a counter".  Thanks! :)

The same issue applies to -webkit-background-origin

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot