Re: [css3-selectors]: Proposal: :in-view() selector for better visibility control

> So, you might say, let's break the loop!  :hover actually gets this
> treatment too - browsers will usually not re-check :hover styles until
> the cursor actually moves; this prevents pages from wiggling
> underneath you when you're just scrolling with a mousewheel or
> touchpad, and also happens to partially defeat the :hover loop - once
> your mouse stops it freezes on either "hovering" or "not hovering",
> somewhat arbitrarily.
> 
> 
> We also don't need to check :in-view statements every time. 
>  

In order to check :in-view statements only once per "frame", you need to define what a "frame" is in a way that  will be interoperable, and deals with things like:
- scrolling
- resizing the window
- transitions (continuous ones vs discontinuous ones)
- animations (continuous ones vs discontinuous ones)
- animations that change the computed styles in ways that result into the same layout
- filling in form controls
- dom modifications that don't affect styles computation
- dom modifications that affect styles computation and layout
- dom modifications that affect style computations in ways that result into the same layout
- hovering over unrelated parts of the document, in ways that affect / don't affect style computations / layout
- progressive rendering as more CSS gets loaded from the network
- progressive rendering as more HTML gets loaded from the network
- progressive rendering as more images gets loaded from the network
- any combination of the above happening at the same time (for some definition of same time)
- different threads for style computations, layout, paint, compositing, scrolling
- parallel layout in multiple threads
- ...

This is likely to be somewhere between "horribly hard to define due to tons of corner cases" and "incompatible with current browser architecture", probably closer to the later.

For example, if we just look at progressive rendering with the way I understand your earlier definition of frame ("statement when browser has finished scrolling tick or layout rearrangement"), it means we would have non deterministic layout.

"body:in-view() {display: none}" may or may not result in an empty document, depending on whether the UA got all its CSS and HTML from the network in one go and did the whole layout in one "frame", or got some bits of it later and did it in two "frames" (or 3, or 12). That's terrible.

Even if we were not doing silly things like ":in-view() {display: none}", many seemingly reasonable uses of use of :in-view() affects layout, and any such use would cause this kind of non deterministic jittery layout.

I don't think there is a definition of "frame" that will work.

:hover is kind of bad, but different (and manageable) because we can break the loop at user interaction. :in-view has a loop inside layout, and that's unsalvageable.

—Florian