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

mstensho has just created a new issue for https://github.com/w3c/csswg-drafts:

== [cssom-view] offsetLeft, offsetTop, offsetWidth, offsetHeight, and fragmentation ==
https://drafts.csswg.org/cssom-view/#dom-htmlelement-offsettop

We need some clarifications for block-fragmented elements. How offsetWidth and offsetHeight are specified already makes sense. We'll use the bounding box of all fragments.

For offetLeft and offsetTop, on the other hand, the spec doesn't seem to be fragmentation-aware. It says to use the offset from the top/left padding edge of the *first box* of the offsetParent to the top/left border edge of the *first box* of the element. Do boxes have well-defined offsets? Fragments do, but boxes?

Consider this:

```html
<!DOCTYPE html>
<div style="columns:3; gap:50px; column-fill:auto; width:400px; height:100px; background:yellow;">
  <div style="height:50px;"></div>
  <div id="parent" style="position:relative; background:cyan;">
    <div style="height:60px;"></div>
    <div id="elm" style="width:90px; height:120px; background:hotpink;"></div>
  </div>
</div>
```

![Image](https://github.com/user-attachments/assets/83bc6696-2016-471c-85ff-73a1373d5e05)

No element here has more than one *box*. But `#elm` hase two *fragments*, and `#parent` has three.

According to the spec, elm.offsetWidth should be 240 (from the left edge of `#elm`'s fragment in the second column to the right edge of `#elm`'s fragment in the third column)  and elm.offsetHeight should be 100.

But what about `offsetLeft` and `offsetTop`? The offset from the first *fragment* of `#parent` to the first *fragment* of `#elm` is 150,-40 (the parent is in the preceding column - column width is 100px, gap is 50px - and the parent is 40px below), But is this meaningful as offsetLeft and offsetTop? One would expect that the rectangle formed by offsetLeft,offsetTop,offsetWidth,offsetHeight would be something sensible, but the rectangle in this case would then be 150,-40,240,100. Relatively to the top/left of the first fragment of `#parent`, that would be the superimposed black rectangle here:

![Image](https://github.com/user-attachments/assets/facab236-abb4-4acc-81b1-0d722f33c89a)

Relatively to the top/left bounding box of '#parent' (which happens to be the entire multicol container):

![Image](https://github.com/user-attachments/assets/e856455b-eafc-41c2-8e70-15ca10940e54)

As can be seen, none of them represent `#elm` relatively to `#parent` in a good way.

I suggest that `offsetLeft` and `offsetTop` be the top/left of the bounding box of all fragments of the element, relative to the top/left of the bounding box of all fragments of the offsetParent. In the example above, that would be 150,0.

No browsers do this currently, and there's hardly any interop. For offsetLeft and offsetTop, EdgeHTML returns the offset from the first fragment of offsetParent to the offset of the first fragment of the element - i.e. 150,-40 for the example above. Gecko returns the offset from the first parentOffset fragment *where the element occurs*, to the first fragment of the element, .i.e. 0,10 in the example above. Blink and WebKit both leak implementation details from the "stitched coordinate system" used internally in some cases, which is 0,60 in the example above.

For offsetWidth and offsetHeight, EdgeHTML and Gecko do what the spec says, and return 240x100. Blink and WebKit leak from the "stitched coordinate system" again, and return 90x120.

@emilio @bfgeek 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11541 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 20 January 2025 13:18:20 UTC