A block has wrong height when it has white-space:pre and an empty child text node
Categories
(Core :: Layout: Block and Inline, defect, P3)
Tracking
()
People
(Reporter: jeffreytse.mail, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(5 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36
Steps to reproduce:
create a pseudo element (::before, ::after), then set padding and backgroud-color as below:
.test::before {
content: '';
color: #fff;
background-color: #ff4e00;
padding: 0 .5em;
}
Actual results:
Pseudo element (::before, ::after) has wrong height when its content is empty but padding is non-zero.
Expected results:
It should have no height, because there is no content to spread its height.
And there is no such problem in Chrome browser (my Chrome Version: 87.0.4280.66 (Official Build) (64-bit)), and the display is normal.
Reporter | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Hi,
Can you please provide us a test page or a reduced case in order to reproduce this issue.
Updated•4 years ago
|
Reporter | ||
Comment 2•4 years ago
|
||
Hi,
Here is the test page with reduced case to reproduce this issue.
The key point is that the display should be the inline-block
.
<!DOCTYPE html>
<html>
<head>
<title>This is a test page</title>
<style>
pre::before {
content: attr(data-lang);
color: #fff;
background-color: #ff4e00;
padding: 0 0.5em;
display: inline-block;
}
</style>
</head>
<body>
<figure class="highlight">
<pre data-lang="python" ><code class="hljs python" data-lang="python"><table class="rouge-table"><tbody><tr><td class="gutter gl"><pre class="lineno"><span class="hljs-number">1</span>
<span class="hljs-number">2</span>
</pre></td>
<td class="code"><pre><span class="kn"><span class="hljs-keyword">import</span></span> <span class="nn">networkx</span> <span class="k"><span class="hljs-keyword">as</span></span> <span class="n">nx</span>
<span class="kn"><span class="hljs-keyword">from</span></span> <span class="nn">collections</span> <span class="kn"><span class="hljs-keyword">import</span></span> <span class="n">Counter</span>
</pre></td>
</tr></tbody></table></code></pre>
</figure>
</body>
</html>
Screenshot on Firefox:
Screenshot on Chrome:
Reporter | ||
Comment 3•4 years ago
|
||
Reporter | ||
Comment 4•4 years ago
|
||
Updated•4 years ago
|
Comment 5•4 years ago
|
||
Comment 6•4 years ago
•
|
||
So what happens in Gecko is that we decide that the block has a line box, given that it has a child box. When we have a line box we apply line-height
to it, which gives it some size based on the font in this case. My gut feeling is that we handle this correctly (for Standards mode layout at least), but I haven't read the relevant specs in detail yet...
This is where the size comes from, fwiw:
https://searchfox.org/mozilla-central/rev/c7cf087b6e1384608ca3989f042f12f7cabd0a5f/layout/generic/nsLineLayout.cpp#2282
Comment 7•4 years ago
|
||
The last paragraph here seems like it addresses this case:
https://drafts.csswg.org/css-inline-3/#line-boxes
Line boxes that contain no text, ... must be treated as zero-height line boxes ...
It depends on what they mean by "no text" in that sentence.
I would assume an empty text node counts as "no text", but the spec could certainly be more precise on that...
Also, there's no indication that white-space:pre
should make a difference (other than for "preserved white space", which this clearly is not) and we do make the height zero for white-space:normal
, so our layout for pre
seems unintentional to me.
Comment 8•4 years ago
|
||
Let's see what breaks :-)
https://treeherder.mozilla.org/#/jobs?repo=try&revision=029fe5112660c42a2873dbca321a679624b314c8
Comment 9•4 years ago
|
||
It broke single-line text controls. We go again:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=66ec627e872bf594affd5e66483992104059a084
Comment 10•4 years ago
|
||
... and it broke <input type=button/submit/reset value="">
. We go again:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=21c812309d023d557ea0e92e53d16b434a6d13ac
Comment 11•4 years ago
|
||
Updated•4 years ago
|
Comment 13•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Comment 14•2 years ago
|
||
The severity field for this bug is set to S4
. However, the following bug duplicate has higher severity:
- Bug 1720699: S3
:jfkthame, could you consider increasing the severity of this bug to S3
?
For more information, please visit auto_nag documentation.
Comment 15•2 years ago
|
||
This appears to have been fixed by bug 1731120.
Description
•