getVisibleClientRect API analogous to getBoundingClientRect

[ExtAnimal]

getBoundingClientRect returns the full laid out DomRect of the element.

A very common use case in complex apps is to want to ascertain the visible rectangle of an element as clipped by all clipping ancestor elements.

This is surprisingly difficult to do in Javascript. Of course you can walk up the parentNode axis, but there are many caveats to navigate when determining whether an ancestor clips and the clipping rectangle of that ancestor which makes the code difficult to understand and maintain.

In the example below, the day's schedule is clipped by the small size of the editor:

In that screenshot I use our utility class to work out the visible client rect for the day column element, and visualize it in red.

It would be very useful for applications to have element.getVisibleClientRect() available. What happens if the element is fully out of view can be discussed. Our utility returns false rather than a zero dimension rectangle, because it is possible to also ask whether a Point is in visible space.

Also, do we not think that the DomRect API is rather insipid? To do anything interesting with rectangles of elements, you have to write your own Rectangle class which wraps or extends DomRect.

How about these new methods?

newRect = firstRect.intersection(secondRect, thirdRect, ...);

newRect = firstRect.union(secondRect, thirdRect, ...);

isWithin = firstRect.contains(secondRect);

And equals, and translate etc?

Maybe these are methods of a lower base class which does not have a relationship to DOM.

Just a Rect class which DomRect extends because it is connected to a Dom element.

So the intersection of two DomRects would just yield a Rect because it is now not connected to any element.

I can't imagine the anchor positioning API was written without these methods being available. They should be public.

[emilio]

Isn't this basically IntersectionObserverEntry.intersectionRect?

[ExtAnimal]

Isn't this basically IntersectionObserverEntry.intersectionRect?

No. It is not. That's part of IntersectionObserver

This is just plain DOM information about an element which should be available in any context and any time.

In our system, all aligning is done to the visible rectangle. This can be tooltips, or editors. Anything that can be aligned. The target rectangle is calculated with regard to all ancestor clipping rectangles.

Any element can be used as an align target at any time. We cannot possibly add IntersectionObservers on every element and constantly track its intersection rectangle as it changes just in case something might want to align to it. The idea is ridiculous.

This is just a basic piece of information which a browser could easily calculate on demand.

[emilio]

Any element can be used as an align target at any time. We cannot possibly add IntersectionObservers on every element and constantly track its intersection rectangle as it changes just in case something might want to align to it. The idea is ridiculous.

Well, there's no need to use that tone. I don't know how you API and I didn't suggest anything in particular.

My point was, is that API doing the computation you want (even if async)?

There are actually a lot of boxes you might care about, and a lot of ways of defining something as "visible". Just for a few examples:

• does opacity count? You can still hit test it.
• What about the visibility property? That still creates a box that is positioned, and might have visible descendants.
• Do you care about pre-transform or post-transform bounds?
• Do you care about descendants of a given element that overflow?
• What about absolutely positioned children that escape?
• What about ancestor frames? Does an element report being visible even if its iframe is scrolled away? What if the iframe is cross-origin?
• What if you're in a background tab?

I was just trying to scope your issue to something more concrete. IntersectionObserver does have answers for those questions.

If your issue can be reworded as "expose a sync version of IntersectionObserver", that is a much simpler thing to discuss than figuring out a complete new API. Does that make sense?

That said, while browsers indeed could have the capability of exposing this info synchronously, the whole reason IntersectionObserver was made async was because they are not simple computations, and people tend to shoot themselves in the foot with apis that force layout very often.

[ExtAnimal]

It should work the same as IntersectionObserver's calculations.

It should be based on the actual layout. The visual attributes such as color or opacity are not related to the problem.

This is purely a layout geometry problem. If a use case is concerned about things like color or opacity or visibility, those can be handled in code.

[SebastianZ]

@ExtAnimal The request for an API that returns the visible visible rect sounds very related to #6132, where you also commented. What would be the difference between the two?

How about these new methods?

newRect = firstRect.intersection(secondRect, thirdRect, ...);

newRect = firstRect.union(secondRect, thirdRect, ...);

isWithin = firstRect.contains(secondRect);

Those seem to go beyond your initial use case, though I agree those can be useful in some cases. And I think there were already some discussions related to such functions, but I can't find them right now.

Besides the points @emilio raised, I am wondering what you'd expect the union() function to return. I assume, you mean the bounding rect around all the given rects. Correct?

Sebastian

[ExtAnimal]

DomRect geometry methods? Yes, they would be generally useful.

Would make no difference to this use case. To calculate the clipped rectangle, you'd still have to walk up the parentElement axis clipping the initial Rectangle within clipping ancestors (determining that is tricksy).

Which is what I do already in a big pile of JavaScript using my JavaScript Rectangle class which already has these methods.

It would just be better done by the browser.

The logic is definitely known by the browser vendors since IntersectionObserver must use it.