Repository navigation
getVisibleClientRect API analogous to getBoundingClientRect #13294
Description
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.
Activity
emilio commentedon Jan 15, 2026
Isn't this basically
IntersectionObserverEntry.intersectionRect?ExtAnimal commentedon Feb 7, 2026
No. It is not. That's part of
IntersectionObserverThis 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
IntersectionObserverson 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 commentedon Feb 7, 2026
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:
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 commentedon Feb 8, 2026
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 commentedon Feb 8, 2026
@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?
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 commentedon Feb 8, 2026
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.