W3C home > Mailing lists > Public > www-style@w3.org > December 2016

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

From: Alexander Shpack <shadowkin@gmail.com>
Date: Tue, 6 Dec 2016 22:26:47 +0200
Message-ID: <CAK4xKXm6bByoz46+diKSLbaM3Uj+6rUpNoaO4Hfw5mM2WsxfQQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Andrea Rendine <master.skywalker.88@gmail.com>, www-style <www-style@w3.org>
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

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

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:05 UTC