Bug 72524 (offsetTopError) - offsetTop incorrect for empty inline elements
Summary: offsetTop incorrect for empty inline elements
Status: UNCONFIRMED
Alias: offsetTopError
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P2 Major
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2011-11-16 10:58 PST by ksev
Modified: 2022-06-19 15:15 PDT (History)
10 users (show)

See Also:


Attachments
Demonstrates offsetTop error in relation to display:inline vs display:block (2.14 KB, text/html)
2011-11-16 10:58 PST, ksev
no flags Details
offsetTop varies based on a single space (1.43 KB, text/html)
2018-08-30 07:27 PDT, Terje Bless
no flags Details
All browsers differ from each other (599.16 KB, image/png)
2022-06-19 15:15 PDT, Ahmad Saleem
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description ksev 2011-11-16 10:58:20 PST
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.
Comment 1 ksev 2011-11-16 14:15:22 PST
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
Comment 2 Darin Adler 2011-11-17 17:46:15 PST
Hyatt, Dan, is this expected?
Comment 3 ksev 2012-04-24 08:56:45 PDT
Getting accurate element position values seems like a high priority issue to me. Is there any hope of getting some action on this bug?
Comment 4 Eric Seidel (no email) 2012-04-24 11:00:44 PDT
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.
Comment 5 Eric Seidel (no email) 2012-04-24 11:01:37 PDT
http://www.w3.org/TR/cssom-view/#offset-attributes
Comment 6 Eric Seidel (no email) 2012-04-24 11:05:13 PDT
http://www.w3.org/TR/CSS2/visuren.html#inline-boxes
Comment 7 Terje Bless 2018-08-27 06:05:45 PDT
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.
Comment 8 Terje Bless 2018-08-30 07:27:30 PDT
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.
Comment 9 Ahmad Saleem 2022-06-19 15:15:15 PDT
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.
Comment 10 Radar WebKit Bug Importer 2022-06-19 15:15:43 PDT
<rdar://problem/95500272>