[Request] [css-pseudo] Selector :viewport

[oleedd]

To select elements which are in viewport at the moment - user can see them (or its position if hidden) without scrolling.

[Loirooriol]

See https://wiki.csswg.org/faq#selectors-that-depend-on-layout for why

I would like a :on-screen pseudo class to select elements which are currently in the viewport

can't be done.

[Loirooriol]

Please read https://wiki.csswg.org/faq#selectors-that-depend-on-layout, it explains why that doesn't work either.

[oleedd]

@Loirooriol
There is a solution for infinity loop - to forbid changing of position for such selectors (with error in console or just not working). What about this? And wiki says "but this works for this case". It is definitely better than nothing.

[oleedd]

No need problem abilities like Toggle States. The talking is only about :on-screen which can be done.

[Loirooriol]

In effect, if we ever add a selector that can depend on properties, then we can never add another selector that would depend on other properties ever. Which one goes first? Something that we can only do once, ever, and that will affect our ability to evolve CSS in the future, is probably a bad idea for the language.

[oleedd]

And what is bad? In case of :hover, browsers blink in infinity loop, so the problem is visible. The developer will see this and fix. And no one will take away an element from the viewport when it is there.

[Loirooriol]

The provided link already explains Why Doesn't This Argument Apply To :hover?

[oleedd]

No, it doesn't. Why is infinity loop bad when it is visible? I don't talk about cases when it is not visible and don't know them.

[Loirooriol]

Please read the linked article. Selectors can't depend on layout (unless some constraints are apply like in container queries). Otherwise it would be circular, which is bad, for the reasons explained there. I don't know what you mean with visible or non-visible cases.

[oleedd]

I have read it several times. Browsers blink on infinity loop, then it is visible and will be fixed. Why is it bad? Idk about invisible loops but the article talks a little about this.

[Loirooriol]

:hover is not great but is not bad, just a dependency on hit-testing. A dependency on layout is what's really bad.

[oleedd]

And why is :viewport bad? Browsers will blink the same way as at :hover. The developer will see the problem and fix it. And it is much more unlikely to make a mistake and loop this.

[Loirooriol]

Just reading you description:

To select elements which are in viewport at the moment - user can see them (or its position if hidden) without scrolling.

So you want to select elements depending on whether they have a non-zero intersection with the viewport, or something along these lines. This is a dependency on layout. It's not like :hover.

[oleedd]

Ok, I have a solution.
The article says about disallowing properties which can cause a loop. It is a bad idea because too many checks. And these properties may be used correctly, without a loop.
The solution:
Browsers should detect css loops, stop such rules and notify about the problem. For example, they detect JavaScript loops and stop them with an error.

[Loirooriol]

Detecting loops at run-time is already covered in the article:

Yet another way you could try to remediate all this would be to do a run-time detection of whether there is a loop in that particular page and disable all the selectors (or properties) involved in that loop. However, this check would have a performance impact, would still have the confusing and hard to debug “action at a distance” problem, on top of which it would require significant changes in browser architecture.

[oleedd]

It is not hard for browsers now. They are very smart now. I think that this opinion is outdated. If they can detect js loops, they can do this for css loops too.

[oleedd]

And they should do this only for rules with such selectors, not for all. Not a big problem.

[tabatkins]

Your question has been fully answered by Oriol. This precise idea has been rejected in the past, and gets suggested so often that we have an explicit FAQ entry for it. All of the reasoning in the FAQ still applies today.