Skip to content

[cssom-view] offsetLeft, offsetTop, offsetWidth, offsetHeight, and fragmentation #11541

@mstensho

Description

@mstensho

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:

<!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

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

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

Image

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    Regular agenda

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions