Do browsers treat negative width on SVG <rect> as zero or as an error for geometry APIs?
0 reputation · 24 Sept 2025, 00:39 UTC
0 reputation · 24 Sept 2025, 00:39 UTC
When an SVG element receives a negative width or height value, the SVG 2 specification marks the value as an error and states the shape should not render. In practice, implementations differ on whether the element remains in the DOM with a zero-size geometry box or is treated as an erroring element that geometry and hit-testing APIs ignore.
The distinction matters for scripts that call getBBox(), getTotalLength(), or attach pointer-event listeners, because a zero-area rect still returns a valid DOMRect and can receive events, while an errored element may return an empty box or throw. CSS geometry properties (width, height as CSS) add another layer: a negative CSS length is invalid at parse time, but a negative presentation attribute may be handled differently by the SVG layout engine.
Which browsers clamp negative width/height to zero and keep the element in the geometry tree? Does getBBox() return a zero-area rectangle or an empty rectangle in each engine? Are pointer events dispatched on a rect with negative size in Chrome, Firefox, and Safari?
31275 reputation · 24 Sept 2025, 06:47 UTC
All three major browser engines treat negative width or height on an SVG <rect> as an error state rather than clamping to zero. The element remains in the DOM but is excluded from the render tree. getBBox() returns a DOMRect with zero width and height (x/y at the rect's position), and pointer events do not fire on the element because it has no hit-testable area.
| Engine | Rendering | getBBox() Result | Pointer Events |
|---|---|---|---|
| Chromium (Chrome, Edge, Opera) | Not rendered | Zero-area DOMRect at x,y | Not dispatched |
| Gecko (Firefox) | Not rendered | Zero-area DOMRect at x,y | Not dispatched |
| WebKit (Safari) | Not rendered | Zero-area DOMRect at x,y | Not dispatched |
The distinction matters. A presentation attribute width="-100" is parsed by the SVG layout engine and triggers the error behavior above. A CSS declaration style="width: -100px" or width: -100 is invalid at the CSS parser level; the declaration is dropped and the initial value (auto, which resolves to 0 for <rect>) applies, so the rect renders at zero size but without an error state. In practice both paths produce a non-rendered, zero-geometry box, but the SVG attribute path leaves the invalid value in rect.width.baseVal.value while the CSS path does not.
const svg = document.createElementNS('http://www.w3.org/2000/svg', 'svg');
svg.innerHTML = '';document.body.appendChild(svg);
const r = document.getElementById('r');
console.log('baseVal:', r.width.baseVal.value, r.height.baseVal.value);
console.log('getBBox():', r.getBBox());
r.addEventListener('click', () => console.log('clicked'));
// Manually dispatch to test listener attachment
r.dispatchEvent(new MouseEvent('click'));
baseVal shows the negative numbers; getBBox() returns DOMRect {x: 10, y: 20, width: 0, height: 0, ...}; the synthetic click fires the listener (proving the listener attaches), but a real mouse click on the page will not hit the rect.Behavior is consistent across current stable versions (Chrome 120+, Firefox 121+, Safari 17+). Older versions (pre-2020) occasionally clamped to zero and kept the rect in the hit-test tree. If you support legacy browsers, test explicitly. The SVG 2 spec wording around "error" handling is ambiguous; engines converged on the current behavior but no formal test suite mandates it.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.