Empty display:inline div element has positive offsetHeight value
Categories
(Core :: Layout, defect, P3)
Tracking
()
| Webcompat Priority | P3 |
People
(Reporter: b_power, Unassigned)
References
Details
(Whiteboard: [webcompat:needs-knowledgebase])
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0
Steps to reproduce:
load the following html in a firefox and look at the console output ;
<html>
<head>
<title>TODO supply a title</title>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<script>
window.addEventListener("load",_ => {
var div = document.getElementById("div");
console.log("div.offsetHeight: ",div.offsetHeight);
})
</script>
</head>
<body>
<div id="div" style="display:inline;"></div>
</body>
</html>
Actual results:
div.offsetHeight: 18
Expected results:
div.offsetHeight: 0
This is what you get in Chrome Version 78.0.3904.70 (Official Build) (64-bit)
and appears to be correct in light of
https://www.w3.org/TR/CSS21/visuren.html#inline-formatting
section 9.4.2 which says ;
"..... Line boxes that contain no text, no preserved white space, no inline elements with non-zero margins, padding, or borders, and no other in-flow content (such as images, inline blocks or inline tables), and do not end with a preserved newline must be treated as zero-height line boxes for the purposes of determining the positions of any elements inside of them, and must be treated as not existing for any other purpose. "
|
||
Comment 1•5 years ago
|
||
The html with outputting the offsetHeight in a pre.
|
|
||
Comment 2•5 years ago
|
||
It works on Firefox nightly, Firefox 71.0b6, Firefox Preview nightly and Fennec 68.
can you please provide more information to reproduce this issue?
(In reply to Hiroyuki Ikezoe (:hiro) from comment #2)
It works on Firefox nightly, Firefox 71.0b6, Firefox Preview nightly and Fennec 68.
can you please provide more information to reproduce this issue?
Apologies, the code to reproduce should be ;
<!DOCTYPE html>
<html>
<head>
<title>TODO supply a title</title>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<script>
window.addEventListener("load",_ => {
var div = document.getElementById("div");
console.log("div.offsetHeight: ",div.offsetHeight);
document.querySelector("pre").innerHTML = div.offsetHeight;
})
</script>
</head>
<body>
<div id="div" style="display:inline;"></div>
<pre></pre>
</body>
</html>
Note the relevant difference is the <!DOCTYPE html> preamble. Without it, it does indeed give the expected 0 value.
My understanding is that it should conform to the specs with the <!DOCTYPE html> ( and any deviation might be expected when the preamble is omitted).
|
|
||
Comment 4•5 years ago
|
||
Thanks! There may be duplicate bugs, but I couldn't find it.
|
||
Comment 5•3 years ago
|
||
Setting WebCompat Priority P2 here because this is breaking charts on a Government website (see see-also).
|
||
Updated•2 years ago
|
|
||
Comment 6•1 year ago
|
||
Clear a needinfo that is pending on an inactive user.
Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.
For more information, please visit BugBot documentation.
How should this be closed as incomplete ? I provided all info to reproduce and it was reproduced and confirmed as a bug by others. I was not asked for further information.
Unless fixed and verified it is still a bug.
|
|
||
Comment 8•1 year ago
|
||
All good. You didn't remove the needinfo flag when providing the answer, so the bot didn't know about this and sent that automated message. :) This bug will stay open until it's fixed.
|
||
Comment 10•8 months ago
|
||
Hi, I just wanted to note a case where this miscalculated offsetHeight can affect the page layout.
Wrapping the empty inline element inside a block element can lead to overflow (in the body in the example below) and cause a scrollbar to appear (although the wrapping block element has zero height):
<!DOCTYPE html>
<html>
<body style="margin: 0">
<div style="height: 100vh; margin: 0"></div>
<div>
<span></span>
</div>
</body>
</html>
I have also observed that:
- Reversing the order (i.e, the wrapping block element and the inner inline element first, and the element which occupies the 100% of the window height after them) does not reproduce the overflow
- Not wrapping the inline element in a block element does not reproduce the overflow either
- The offsetHeight of the inline element is equal to the font size
- The difference between the body's scrollHeight and offsetHeight (which causes the overflow) is one quarter of the font size.
|
||
Comment 11•8 months ago
|
||
Removing the webcompat priority for now, as we don't have any known site breakage right now (the government site in comment 5 no longer has the issue, and the link in bug 1850236 now seems dead/inaccessible).
|
||
Comment 12•7 months ago
|
||
I think I found a website that breaks because of this bug, but it only happens when JavaScript is disabled. (I think that’s still valid and should count as a webcompat issue.)
- disable JavaScript in Firefox
- open https://www.france24.com/en/
- notice how there is a double scrollbar and how it is not possible to scroll the page unless the mouse cursor is hovering the site header
I have debugged this problem with the help of other people on Mastodon 1. Basically, if the page has overflow-x: hidden on both the <html> and <body> elements, then any in-flow block element with an empty inline element will cause the double scrollbar and prevent normal scrolling. I’m attaching a minimal reproducible example.
|
|
||
Comment 13•7 months ago
|
||
|
||
Updated•7 months ago
|
|
|
||
Updated•7 months ago
|
|
||
Comment 14•7 months ago
|
||
I can reproduce this in release but not in nightly, so I wonder if the bug was actually fixed recently?
Description
•