Move CSS env()/var() functions into css.types.*

[caugner]

Summary

Moves env() from css.properties.custom-property to css.types.

Test results and supporting details

Related issues

Fixes #14668.

[queengooborg]

I think that we should also move var() if we're moving env(), WDYT?

[caugner]

I think that we should also move var() if we're moving env(), WDYT?

Good point, that probably makes sense.

PS: Wouldn't it also make sense to introduce css.functions.*? It seems weird that we mix CSS functions and CSS data types under css.types.*.

[caugner]

@Elchi3 Please let me know if you have any concerns here.

[ddbeck]

I'm fine with this PR.

PS: Wouldn't it also make sense to introduce css.functions.*? It seems weird that we mix CSS functions and CSS data types under css.types.*.

Previously:

• Add compat data for symbols() CSS function #642
• CSS folder structure - add functions folder #10563

No, don't do this. Types are a bit dubious to begin with and giving functions their own namespace would compound the error. It would also trigger a lot of needless work for consumers.

Types are a convenience for specification authors, much like IDL mixins. Browsers don't actually have to implement the specified type system, just the properties and descriptors that consume concrete values that correspond to their specified type. There are many examples of supported BCD "types" that only work incompletely across all the properties spec'd to use that type or whole types that are partially implemented (#18198). It's messy and fixing it would require significant work, comparable to flattening mixins (#8929).

Besides, a lot of CSS functions are a functional notation for a type (e.g., translateX() or url()). With the exception of a few oddities like var(), there are few composable functions in CSS as a language.