You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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:
Relatively to the top/left bounding box of '#parent' (which happens to be the entire multicol container):
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.
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:
No element here has more than one box. But
#elmhase two fragments, and#parenthas 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
offsetLeftandoffsetTop? The offset from the first fragment of#parentto the first fragment of#elmis 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:Relatively to the top/left bounding box of '#parent' (which happens to be the entire multicol container):
As can be seen, none of them represent
#elmrelatively to#parentin a good way.I suggest that
offsetLeftandoffsetTopbe 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
The text was updated successfully, but these errors were encountered: