[quote=“MerlinMason, post:8, topic:621”]
This is obviously a huge issue as :hover can be applied to all elements and potentially start infinite layout loops.[/quote]
Yes, but importantly, :hover is limited by the speed at which you detect user interaction. For example, you could “fix” it by only checking for :hover states on a mousemove event, so the :hover would trigger, then stay triggered even if the element was no longer under the mouse. When the loop is instead triggered purely by internal processing, it can cycle much faster, and it’s much harder to break or slow loops by rate-limiting parts of the algorithm.
Also, the :hover flicker is extremely annoying, so authors avoid doing it as soon as they encounter it.
Detecting loops is actually rather expensive; it’s much better to avoid making them possible in the first place. We do allow for the possibility of loops in some cases (for example, @counter-style rules can depend on other @counter-style rules; a loop causes them to all break their dependencies), but finding and dealing with loops in layout is, as far as I can tell, too expensive to be worth doing.
More importantly, it doesn’t actually help. You can’t use the “just don’t use properties that would affect the selector” approach, because as soon as you add a second selector with a different set of properties, the two can communicate: in a rule with Selector 1, you can use a property that affects Selector 2, then in a rule with Selector 2 set up to respond to that, you can use a property that affects Selector 1, thus bypassing the protection and reintroducing the cycle.