chore(css): remove not-supported values for text-spacing-trim

[skyclouds2001]

Description

the trim-both trim-all auto values are in spec but not supported by any platform yet

see spec https://drafts.csswg.org/css-text-4/#propdef-text-spacing-trim and mdn docs https://developer.mozilla.org/en-US/docs/Web/CSS/text-spacing-trim

Motivation

Additional details

see also https://github.com/skyclouds2001/mdn-tools/blob/master/docs/not-fully-supported-feature.md

Related issues and pull requests

[bsmth]

Thank you! While this is correct, I'm curious if consumers want all spec values even if not supported yet. I can imagine cases where a user wants to know possible property values according to spec, even if implementations haven't caught up. Additionally, we won't have to revisit when these are actually added (in BCD, for instance), or we won't forget to add at a later point.

So I see two cases where mdn/data and bcd diverge:

• removed (something is being removed from the web platform)
• not yet supported

I think for the not-yet supported things, we may leave the entries in here. Something is being removed, I think it's safe to delete.

[skyclouds2001]

While this is correct, I'm curious if consumers want all spec values even if not supported yet. I can imagine cases where a user wants to know possible property values according to spec, even if implementations haven't caught up.

I think in those cases, consumers is better to use w3c/webref for the latest data directly offered from the spec. See also #585.

Additionally, we won't have to revisit when these are actually added (in BCD, for instance), or we won't forget to add at a later point.

Yes, it is true. But it all goes the same as mdn/content and bcd in some cases. But this can be improved by script or CI by checking automatically and periodically, like using data from webref to check features in mdn/data. Here's how skyclouds2001/mdn-tools will take effect.

So I see two cases where mdn/data and bcd diverge:

• removed (something is being removed from the web platform)
• not yet supported

mdn/content and mdn/browser-compat-data mostly add new css features when they are supported, and remove not supported css features for a long time. For features add but not supported, mdn/browser-compat-data prefers to directly remove it, while mdn/content may either directly remove it or keep it but add enough and clear info indicate the feature is not supported.

Other than w3c/webref, mdn/data can be used to reflect the actual state of CSS. See also mdn/mdn#166 (comment).

I think for the not-yet supported things, we may leave the entries in here. Something is being removed, I think it's safe to delete.

I think it is better to follow the similar behavior like mdn/browser-compat-data - only keep values that has been supported by at least one engine.

But not-supported feature, it is possible that it will never got implemented, for example the feature itself is non-standard, or the value or the feature itself has been removed from spec, or the value or the feature itself has been renamed to another value or feature.

And not-supported values are useless because it can not be used. See also #136 (comment).

[skyclouds2001]

Also notice that such cases existed for removing not-supported values of CSS features, like #775, #677, #417, #32 and more.

[bsmth]

I think it is better to follow the similar behavior like mdn/browser-compat-data - only keep values that has been supported by at least one engine.

Thanks a lot for the thoughtful response, I think the points you're making are convincing. For now, I'd like to merge to unblock this cleanup work, but it would be great to get some guidelines in place (in this repo) for cases like this. The opinions of consumers would mostly guide this decision, so I hope we get some input on that soon.