The DOM has corners.

The web platform has always been excellent at laying things out, but surprisingly reluctant to tell us the exact geometry it produced. That becomes a problem the moment an interface needs to draw on top of the page instead of merely living inside it.

Consider a visual editor. The selected component might sit inside three transformed ancestors, a scrolled container and an iframe. To draw a precise outline, resize handles or a connector, the editor needs the component’s real corners in a coordinate space it controls. An axis-aligned rectangle is no longer enough.

01

One method, four honest corners

getBoxQuads() is part of the CSSOM View GeometryUtils interface. Call it on an Element, Text node or Document. It returns an array because one node can produce multiple fragments—for example, inline text wrapping across lines.

const [quad] = selectedElement.getBoxQuads({
  box: "border",
  relativeTo: overlayLayer,
});

const corners = [quad.p1, quad.p2, quad.p3, quad.p4];
overlayPath.setAttribute(
  "points",
  corners.map(({ x, y }) => `${x},${y}`).join(" ")
);

The box option chooses margin, border, padding or content. The relativeTo option is the quiet superpower: it asks the browser to express those points directly in another node’s coordinate system.

03

Coordinate conversion, without matrix archaeology

The rest of GeometryUtils solves the inverse problem: you already have a point, rectangle or quad, but it belongs to the wrong node. The conversion methods move that geometry from one local coordinate system into another while accounting for the transforms between them.

• convertPointFromNode()Map a cursor, anchor or handle.
• convertRectFromNode()Move a rectangular region between nodes.
• convertQuadFromNode()Preserve all four corners across spaces.

// local → workbench: place the transformed marker
const pointOnWorkbench = workbench.convertPointFromNode(
  localPoint,
  transformedSpace,
);

// workbench → local: handle a click on the transformed grid
const localPoint = transformedSpace.convertPointFromNode(
  clickOnWorkbench,
  workbench,
);

04

Where precise DOM geometry earns its keep

This is not only a low-level browser curiosity. It is the missing primitive behind a broad family of interfaces that must understand the page visually.

Already used in practice

05

Using it today

Until native implementations are consistently enabled across engines, feature detection plus a polyfill is the pragmatic route. The polyfill adds the GeometryUtils methods to Node and keeps application code close to the standard API.

npm install get-box-quads-polyfill

import { addPolyfill } from "get-box-quads-polyfill";

if (!("getBoxQuads" in Element.prototype)) {
  addPolyfill(window);
}

const quads = element.getBoxQuads({
  box: "border",
  relativeTo: document.body,
});

A polyfill can reconstruct only the geometry JavaScript is allowed to observe. This one focuses on HTML and has limited SVG and MathML support because some nodes do not expose layout properties such as offsetLeft and offsetTop. Shadow DOM adds similar hard boundaries: open roots and common slotting cases can be handled, but closed or otherwise inaccessible trees—and browser-internal layout details across those boundaries— cannot be recovered reliably from page script. Those are platform limitations, not missing matrix math. For repeated measurements the polyfill also provides an optional cache; clear it whenever layout changes.