How to represent clip-path?

[foolip]

We already have a masks feature, but not one for https://drafts.fxtf.org/css-masking/#the-clip-path from the same spec.

https://developer.mozilla.org/en-US/docs/Web/CSS/clip-path#browser_compatibility is a bit messy and I need advice.

@progers how do you think we should represent this? Should we do like https://caniuse.com/css-clip-path and have a single feature that's still not fully supported? Or can it be split into smaller parts? If so, what are those smaller parts?

[foolip]

In #1129 I've grouped the BCD entries by browser versions, that might help. There are so many incremental steps here and I'm pretty sure we shouldn't retain all of the nuance. My main question is if we should have an "initial support" feature for this, and what the "full support" feature should then be called? Is there a single identifiable thing that we can put in the name of a second feature?

[foolip]

This situation would be easier to deal with if we had #915.

[captainbrosset]

My two cents is that we should have some kind of initial support feature for clip-path. I've used it with basic circle and polygon shapes for ages and would find it weird if the feature was marked as non baseline.

Maybe we call it something like "basic shape clip path".

[progers]

Fredrik (fs@opera.com) is actively working on https://crbug.com/40134477 which is the bug tracking Chromium's implementation of external resources for clip-path/filter/stroke/etc. The +1 count on that bug indicates it is an important feature for developers. External mask-image references were part of the css-masking area of interop-2023, which is another datapoint that developers care about this. The lack of external resources for filter/stroke/etc is not reflected on caniuse for other properties (e.g., https://caniuse.com/css-filters). However this is handled, we should be consistent about the external resource issue for clip-path/filter/mask/etc.

@foolip , do you have enough information to make a call on this?

[foolip]

Thank you @progers! It sounds like external resources is the only bugs/limitations that we should either treat as separate follow-on features, or track with notes and possibly partial support. And we should probably make the same call for https://caniuse.com/css-clip-path and https://caniuse.com/css-filters.

Since we currently don't have partial support or notes the only option in the immediate term is to align with https://caniuse.com/css-filters and make no mention at all about external resources.

But since there is no urgency to add this feature right now, I think we should block on #915.

[mirisuzanne]

To me this seems like a case where the sub-feature is consistently supported across browsers, and the un-supported aspect can be treated as a new feature if/when it gains traction. I agree with @captainbrosset here that is seems strange to hold up features that have broad support and usage, just because there is more functionality expected down the road.