Add motion path feature

[ddbeck]

Corresponds to https://caniuse.com/css-motion-paths

I think we might need an "also known as" field for this kind of thing. I wonder if this name will stick, long-term, without it being the name of a property directly.

This is a new feature. Expand for ideas for reviewing it.

• Is this a recognizable web feature to web developers? (caniuse features are often made by request, so it's likely, but let's double check our work here.)
• Is this a reasonable identifier for the feature?
• Does this have a reasonable spec link?
• Does this have a reasonable caniuse reference?
• Are the mdn/browser-compat-data features plausible pieces of the feature as a whole?
• Are any pieces missing?
• Are any of the listed features later additions, part of a distinct sub feature, or otherwise excludable?

[Elchi3]

Thanks Daniel! This PR was useful to me when I wanted to find relevant BCD data entries for "CSS Motion Path" in order to update them all for Chrome 116. I think the property list is complete. However, because MDN also documents CSS types separately sometimes, there are also detailed docs on the ray() function. The BCD data points you could include for that are:

• css.types.ray
• css.types.ray.position
• css.types.ray.size

Also, there are some new <basic-shape> functions that are relevant here, but I'm not sure if it would be worth including them. The chromestatus entry mentions them with Motion Path, however: https://chromestatus.com/feature/5124394449371136.

[dipikabh]

Hello Daniel. For the sake of completeness, perhaps the feature list can/should also include css.properties.offset-path.url – based on the syntax in the motion path specification and corresponding documentation.

[foolip]

For this feature I think we'll ultimately need notes and a concept of partial support before the recent improvements in implementations. Maybe we'll need to create a subgroup for "basic support", but for now I suggest just listing all of the compat entries, and dealing with this problem as a manual override, since we'd compute the wrong versions based on the data directly.

@ddbeck can you include the css.types.ray entries and css.properties.offset-path.url?

[ddbeck]

The reason I did not include css.types.ray or css.properties.offset-path.url is that neither is well-supported, unlike the rest of the features. This would cause us to break with the linked caniuse feature pretty significantly. That is, compare these two views of support:

• https://developer.mozilla.org/en-US/docs/Web/CSS/ray#browser_compatibility
• https://caniuse.com/css-motion-paths

I'm OK with making that judgment—I don't take it as a given that caniuse is always right—but I think we ought to go into it intentionally.

[foolip]

I think that regardless of the scope we pick, we'll need to communicate clearly what is and isn't in that scope, since there is a feature developers know as motion path that's existing for a long time, with some significant recent improvements to interoperability. Although it's notable that https://bugzilla.mozilla.org/show_bug.cgi?id=1598151 hasn't actually shipped yet.

How about filing an issue (or draft PR) for the newer bits of motion path so that we don't lose sight of this? With that, I think it's fine to merge this with the current scope.

[foolip]

Do you want to exclude this given https://developer.mozilla.org/en-US/docs/Web/CSS/offset-path#browser_compatibility? In fact it seems like css.properties.offset-path.path is the only subentry that we should include if we want this to be "old supported stuff"...

[ddbeck]

How about filing an issue (or draft PR) for the newer bits of motion path so that we don't lose sight of this? With that, I think it's fine to merge this with the current scope.

Yes, OK. I am going to remove the features that prevent this feature from showing as fully-supported as it does on caniuse and park them in #445.