https://github.com/w3c/web-platform-tests/pull/7632 adds a WPT test for this.

Hi, this is broken on Stable without lazy parsing turned on. To confirm, lazy parsing isn't causing a regression here right?  

Without having actually checked, I'm pretty sure lazy-parsing is not the issue here.

So we need to actually cascade and resolve variables to know which attributes need a LocalStyleChange due to content: attr().

LocalStyleChange is normally not a heavy operation. The presence of attr() in a custom property and.

On a second thought, we can do the whole attribute for content invalidation differently, and potentially more targeted as well. The only time we need to invalidate for attribute changes in that case is when all these are true:

1. We already have generated ::before or ::after content on a given element.
2. Some of the ::before or ::after content was generated by attr().
3. An attribute referenced by attr() was changed on the element generating ::before or ::after.

Currently we set invalidates-self on the attribute invalidation set. That means we'll get LocalStyleChange on every element where that attribute is changed, even if that element does not generate ::before/:after. Instead, we could simply always do LocalStyleChange on an element which has an attribute change when 1 and 2 above is true. Actually, it should be enough to have a LocalStyleChange on the ::before and ::after elements (I don't remember exactly how that works today with LocalStyleChange on the generating element).

If it wasn't clear in the section above this suggests that we don't update attribute invalidation sets from attr() values.

Reading through this and came across a potentially unfinished sentence: 

"The presence of attr() in a custom property and.<insert missing text?>"

Oops. Something like:

The presence of attr() in a custom property and a custom property reference in a content declaration may cause the need for a LocalStyleChange when an attr changes. We'd need to potentially inherit custom properties down the tree to know which attribute change may cause the need for invalidation.

Doing this properly looks complicated.

An alternative solution is to mark pseudo elements which generate content from attr() functions with a flag and do a kLocalStyleChange for the pseudo element for any attribute changes on the originating element. Currently, we would do a kLocalStyleChange on the originating element on "attr" changes on any element if at least one used style rule has a content:attr(attr).