Description
In theory, it's possible to write an ident() function with an argument that's not resolvable until used-value time. For example, in a property that accents idents and length-percentages, and handles those percentages at used-value time, writing ident(foo calc(100% / 50px)) would do this. (Recall that ident() can take integers.)
This is a problem - in general, properties that take idents don't know how to be used-value time values. That's something the property has to be explicitly prepared for, and other properties that need to depend on that value also need to be aware of it.
The same applies to string().
I don't know of any way to handle this generically, so I think we just need to disallow it. Proposal: when an ident() function's arguments aren't fully resolveable at computed-value time, the ident() instead resolves to the guaranteed-invalid value (making its property IACVT).
@andruud wonders if we can instead handle this at parse time, but I'm not sure. I don't know, off the top of my head, whether it's always knowable at parse time whether a particular value will be resolvable at computed or used value time, or if that might possibly be dynamic based on other properties. And, even if it's always knowable now, I'm not certain we want to bind our future design decisions with the need to maintain that invariant. So I lean towards my proposed solution of handling this at computed-value time, unless others have strong opinions about this.