How is interactivity dealt with?

“How does Warhol handle interactivity like :hover or interactive classes on components?”

At the moment Warhol does only very little with interactivity. Warhol's core is in principle able to check each and every interactive state of every element for errors, but not much of this is in use at the moment. Currently every element is treated as if it had no interactivity at all. Every :hover or :active style you declare is invisible to Warhol, as are :link, :visited and even :hover:not(:active). This will change somewhat soon, but the problem to be solved here is rather hard.

Our goal is to have Warhol to check the entirety of a web page for design errors in seconds. Interactive states like :hover make this hard for a multitude of reasons:

First off: what we want to solve here is basically impossible. There is no way to query an HTML element's interactive styles unless the element currently is in the relevant interactive state. For many kinds of interactive states like :hover there is not even a way to manually trigger the state (apart from physically moving the mouse), and even if there was a way, the styles reported back may not be accurate. We have solved this part of the overall problem pretty well.
A more subtle sub-problem is state proliferation via combination, which arises because many interactive states can apply at the same time. If an <a> element has distinct styles for its :hover and :active states, a combined :hover:active state is implied - that is three states in total (plus the element's base state). Add :focus into the mix and there is a total of 7 + 1 states, combined or otherwise. The total number of states we have to check (and, in the case of components, to store) gets really huge really fast and also affects an interactive element's pseudo elements and children. This is a challenge for performance. We know how we can keep this under control, but not much of the mechanisms to support this has been implemented at this point.
Any design discrepancies that Warhol detects in interactive states are essentially predictions of future design discrepancies. Put in another way, Warhol will complain about problems that are not really there (yet). We have to figure out a way to present this information in a way that anyone can understand.
There must be a way to define custom interactive states on components, something like the classes .opened and .closed on a collapsible component. This will require extensions to the component configuration syntax, which is something which we have not yet designed.
The fact that non-standard pseudo elements like ::-webkit-slider-thumb and ::-moz-slider-thumb can have their own interactive states (unlike ::before and ::after) is one of many more smaller complications.

Long story short: we are working on supporting interactive states, but we are not quite there yet. Expect a slow roll out of support for interactive states over time.