- From: Morten Stenshorne via GitHub <noreply@w3.org>
- Date: Wed, 15 Oct 2025 07:26:33 +0000
- To: public-css-archive@w3.org
I also think I agree that this makes sense. And this is more or less how Blink used to behave, but not anymore. I filed this issue back when I had to update the implementation, and decisions had to be made, and back then I was under the impression that it should behave in a more "visual" and fragmentation-aware way, like Gecko does. So I did that as part of the implementation update, since I had no feedback on this issue back then. Blink's current implementation, FWIW: `offsetLeft` and `offsetTop` are relative to the location of the first fragment generated by the element's `offsetParent`. `offsetWidth` and `offsetHeight` is the size of the bounding box of each fragment's border box. All this is similar (but not exactly identical) to what Gecko does. See e.g. how https://drafts.csswg.org/cssom-view/#extensions-to-the-htmlelement-interface defines `offsetWidth`: > Return the [unscaled](https://drafts.csswg.org/css-viewport/#unscaled) width of the axis-aligned bounding box of the [border boxes](https://www.w3.org/TR/css-box-4/#border-box) of all fragments generated by the element’s [principal box](https://www.w3.org/TR/css-display-4/#principal-box), ignoring any [transforms](https://drafts.csswg.org/cssom-view/#transforms) that apply to the element and its ancestors. -- GitHub Notification of comment by mstensho Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11541#issuecomment-3404956432 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 October 2025 07:26:34 UTC