Re: [csswg-drafts] [cssom-view] offsetLeft, offsetTop, offsetWidth, offsetHeight, and fragmentation (#11541)

The CSS Working Group just discussed `[cssom-view] offsetLeft, offsetTop, offsetWidth, offsetHeight, and fragmentation`, and agreed to the following:

* `RESOLVED: Use stitched-together geometry for offset*`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> TabAtkins: Morton brought up question of how offsetLeft/Top/Width/Height should work in the case of fragmentation<br>
&lt;fantasai> TabAtkins: e.g. for a box inside a multicol, that's fragmented<br>
&lt;fantasai> TabAtkins: Should it be based on a single fragment, the bounding box, or the unfragmented bounding box -- i.e. what it looks like within the fragmentation context<br>
&lt;fantasai> TabAtkins: Elika argued that WebKit implements the third option, and that this is consistent with how anchor positioning works as well<br>
&lt;fantasai> -> https://github.com/w3c/csswg-drafts/issues/11541#issuecomment-3114712532<br>
&lt;fantasai> TabAtkins: When you're inside a fragmented context, the anchor looks unfragmented. (If outside you take the bounding box.)<br>
&lt;fantasai> TabAtkins: Proposal is to adopt fantasai's proposal<br>
&lt;fantasai> astearns: Morton's OK with changing, but also requires a Gecko change<br>
&lt;fantasai> TabAtkins: Chrome and Firefox have similar but different behavior<br>
&lt;fantasai> emilio: Changing Gecko here is also fine<br>
&lt;fantasai> emilio: I don't expect these properties on fragmentainers to be super used, esepcially since not interoperable<br>
&lt;fantasai> astearns: I can see utility in any of these options, but happy to go along with this resolution<br>
&lt;fantasai> TabAtkins: Big reason to go with WebKit's behavior, if you're using these to position something else in this context, using the unfragmented behavior will get you the right coordinates<br>
&lt;fantasai> TabAtkins: if you use fragment or bounding-box coordinates you'll get nonsense.<br>
&lt;fantasai> TabAtkins: If you need screen coordinates, you can use getBoundingBox<br>
&lt;fantasai> astearns: If you intend to be in some other fragmented portion wouldn't work<br>
&lt;alisonmaher> q+<br>
&lt;fantasai> TabAtkins: No, what I'm saying the unfragmented space, I mean the stiched-together fragments<br>
&lt;alisonmaher> q-<br>
&lt;fantasai> TabAtkins: so if size of something changed due to fragmentation, it would be taken into account here<br>
&lt;astearns> ack fantasai<br>
&lt;emilio> fantasai: just wanted to clarify that we're stitching these together<br>
&lt;emilio> ... at some point we might have different boxes like narrow page + large page<br>
&lt;emilio> ... if so probably we should start align and get the bounding boxes<br>
&lt;alisonmaher> +1 - was going to suggest the offset when stitched, not strictly the unfragmented offset<br>
&lt;emilio> ... so the top left are first fragment<br>
&lt;emilio> ... height is the stitched height<br>
&lt;emilio> ... width is the width of the largest fragment<br>
&lt;fantasai> astearns: so proposal is to use the stitched-together geometry, matching WebKit<br>
&lt;fantasai> PROPOSED: Use stitched-together geometry for offset*<br>
&lt;fantasai> RESOLVED: Use stitched-together geometry for offset*<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11541#issuecomment-3407376252 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 16:42:53 UTC