How is interactivity dealt with?
“How does Warhol handle interactivity like
:hoveror 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
:active style you declare is invisible to Warhol, as are
: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
:hoverthere 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
:activestates, a combined
:hover:activestate is implied - that is three states in total (plus the element's base state). Add
:focusinto 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
.closedon 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
::-moz-slider-thumbcan have their own interactive states (unlike
::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.