Bug (offsetTopError) – offsetTop incorrect for empty inline elements

• Component: New Bugs
• Status: UNCONFIRMED

[ksev]

Created attachment 115408 [details]
Demonstrates offsetTop error in relation to display:inline vs display:block

The offsetTop value for default empty anchor and span elements is incorrect. It is typically, 0 or some lesser number than the actual offset. When the CSS display value is changed to block, the offsetTop value is correct. This does not occur in IE or Firefox.

Also, if this helps, it also happens in Konqueror (KDE 4.4.3) on Linux Fedora 11.

[ksev]

Here's a link to the stackoverflow question that led to logging this bug:

http://stackoverflow.com/questions/8126648/how-to-get-the-correct-offset-top-value-from-webkit-chrome-safari-with-jquery

[Darin Adler]

Hyatt, Dan, is this expected?

[ksev]

Getting accurate element position values seems like a high priority issue to me. Is there any hope of getting some action on this bug?

[Eric Seidel (no email)]

This seems expected from a WebKit perspective.  (Based on how inlines are laid-out/drawn.)  We'd have to find a spec which covers offsetTop to understand if it's expected from a spec/web perspective.

[Eric Seidel (no email)]

http://www.w3.org/TR/cssom-view/#offset-attributes

[Eric Seidel (no email)]

http://www.w3.org/TR/CSS2/visuren.html#inline-boxes

[Terje Bless]

Since the original bug is a bit short on a description, I'll try to summarise: empty elements with display:inline return an incorrect .offsetTop. Setting the same element to display:block makes .offsetTop() return the correct value. @ksev's original attached test case demonstrates this (alteredOffset.top is the element manually set to display:block, anchor.offset().top is the display:inline version).

This bug is still present as of whatever WebKit version is in Safari 11.1.2 (13605.3.8), and it bit me in production on one of the Wikimedia project sites (English Wikisource). As best I can tell there's no really good workaround: if you have a empty inline element it's probably for a good reason, and either adding filler content or turning it into a block element will be at best awkward (and in my particular case, I have no influence over the layer of the stack that's generating the HTML).

Can also confirm this is still working correctly in latest Firefox, and in IE11 (which is what I happened to have lying around). Latest Chrome, however, has the same bug.

[Terje Bless]

Created attachment 348496 [details]
offsetTop varies based on a single space

Additional test case that demonstrates the insanity of the current behaviour.

Four lines of text (broken with br), where the empty span in line 3 has a lower .offsetTop than that in both lines 2 and 4. The difference between the lines is that in line 3 the span has two literal space characters in front of it, while lines 1,2, and 4 have a single space character. (other seemingly random differences can produce the same effect: for instance, adding a space after the span in line 4 will change its offsetTop). All four elements report their .offsetParent to be the body element.

Empty or not, the reported position of a span element should not be affected the number of space characters in front of it, and it makes no sense for the middle of three following span elements to have its position calculated differently.

Or put another way, absent something that actively fiddles with positioning, empty inline elements should be treated identically to non-empty inline elements, at least as far as where their "top" is. Even a point (no area) has an x and y coordinate.

[Ahmad Saleem]

Created attachment 460338 [details]
All browsers differ from each other

From the attached latest test case in Comment 08 (also similar case with other test case), none of the browser match each other in all four cases as can be seen from the attached screenshots.

I performed this testing using Safari 15.5 on macOS 12.4.

[Radar WebKit Bug Importer]

<rdar://problem/95500272>