[css-cascade-4] Normalize other common steps in the cascade

[gregwhitworth]

I brought this up in #411 but wanted to be good issue citizen so I'm forking the second request into its own issue since it impacts the cascade spec rather than variables. To provide some context as to why I would like to normalize the steps that occur for substitution along with the others (transitions, animations) etc is so that we can better discuss the impact of new features.

This issue initially arose when discussing variables and people would say they would hit a "substitution" point and was further exacerbated by @apply using similar terminology in discussions. When speaking with @shans and @esprehn about the apply at-rule I was asking questions that implementations had hit with custom props, like, how many times do you need to run it, etc as there are performance costs and this space is already an area we always try to limit cycles if possible.

Basically, we should define within the cascade what a substitution step entails (brief summary of variable substation with link to full substation section of variables). And then the same for the apply at-rule. Additionally within each of these specs (as noted in #411) we should outline the possible count necessary to ensure various use cases still work. There were a few that didn't initially work with variables if you only did 1 substitution, so you need to increase it to 2 when necessary.

There may be other steps that I haven't noticed are missing, but it would be great to add those as well.

[tabatkins]

One of the reasons I'm happy to abandon @apply is to avoid the decent amount of added complexity that its substitutions require. ^_^

We do need to go into more detail about the interaction of variable substitution and animations, certainly.

[gregwhitworth]

@tabatkins Let me know if you need a hand

[gregwhitworth]

@tabatkins @fantasai Can you all please let me know what's happening in this space. I understand you both have a million things on your plate, but I would like to see this through to completion before I forget why I cared in the first place :)

[tabatkins]

Now that we've officially abandoned @apply, I don't think we need to do anything with this issue, right?

[gregwhitworth]

@tabatkins I think we should still have it defined, it's what's occurring in engines. Then if anyone else comes along down the road and wants to bring in something new (at-apply or not) they can take into account the various other steps and how to resolve them.

[tabatkins]

I closed #411 because I've established it's a generic animation issue instead; it's just about computed-value dependencies when animations are involved.

I believe this is the same, just more general - afaict there's nothing about variables resolution that makes it distinct from other computed-value dependencies. So I'm going to close this as well.