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

This then ends up being super-complex and unstable. I'll explain further
> below.
>

Versioning algorithms works for the years perfectly in RDBMS. Without any
troubles with a stability and without super complicity. It's not new thing
at all.


> This suggestion, tho, is different - it's a much "tighter" loop,
> detectable as soon as layout as performed.  This means that, if we
> want a consistent page, we have to go back and recalculate styles as
> soon as we do layout, before we even get to paint anything.  Loops
> here are equivalent to a infinite loop in JS code - it prevents the
> browser from doing anything unless you kill the page.
>

I'm not a junior in CS ;) I understand you and your point of view very
well.


>
> 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.


> For in-view styling, we theoretically have to re-check any time *any*
> styling is updated *anywhere* on the page, in case the new styling
> moved or resized the element in question.
>

Theoretically. All time re-checking is not needed. Think about it like it
is an animation keyframe. Does an animation re-painting and rearrangement
hell? Think no. Produces it loops? No. Why? Because it's finite process in
one period of time.

-- 
s0rr0w

Received on Tuesday, 6 December 2016 20:27:22 UTC