Margin on <br> affects layout, unlike on other browsers
Categories
(Core :: Layout: Block and Inline, defect, P3)
Tracking
()
Webcompat Priority | P3 |
People
(Reporter: t, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0
Steps to reproduce:
Visit https://www.2uo.de/imprint/ with Firefox 73 or 74 (presumably also older ones, but I can definitely say it for these two).
Actual results:
The last <p></p> (after <h2>schnelle Erreichbarkeit</h2>) has too much space between <h2> and <p>. It looks like Firefox incorrectly adds a leading empty line to the <p>
DevTools show that it's not margin or padding, but actual box size that's inflated.
This does not happen for the other two, parallel <h2>/<p> constructions before that last one.
Neither does it happen for current MS Edge, MS IE 11, iPadOS Safari, iOS Safari, nor Chrome.
Expected results:
Consistent spacing between <h2> and <p> throughout the page.
Comment 1•4 years ago
|
||
The problem seems to be with this rule, that gets applied to the anchor element in that paragraph. If you disable the rule, or remove the link, the top margin goes away.
* + *
{
margin-top: 1.5rem;
}
Indeed, it doesn't happen on Chrome.
Not completely sure I picked the right product::component, in case feel free to move.
Comment 2•4 years ago
|
||
The problem is that that rule applies to the <br>
and on Firefox it has an effect, but not on other browsers:
data:text/html,<p>Foo<br style="margin: 200px"></p>
Comment 3•4 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
The problem is that that rule applies to the
<br>
and on Firefox it has an effect
There's a <br>
also in the second section (Postanschrift
), but no additional top margin?
Comment 4•4 years ago
|
||
That one doesn't match the * + *
rule.
Reporter | ||
Comment 5•4 years ago
|
||
I hesitate to interrupt you, because I obviously know much less about CSS than you, but could you spare a moment to explain it to me?
In my mind, both occurrences ("Postanschrift" and "schnelle Erreichbarkeit") are parallel: <p>Text1<br>Text2</p>.
Why does the * + * match one of the <br>, but not the other? I can see in the DevTools now that you're right, but I don't get it.
Furthermore, if the <br> has top-margin: 24 (and I can see that now, too), why doesn't it "push away" the "E-Mail"? Does the <br> coincide with the <p>, that is, is the top of the <br> equal to the top of the <p>?
Comment 6•4 years ago
|
||
(In reply to Thomas Hühn from comment #5)
I hesitate to interrupt you, because I obviously know much less about CSS than you, but could you spare a moment to explain it to me?
Sure, please feel free to ask away :)
In my mind, both occurrences ("Postanschrift" and "schnelle Erreichbarkeit") are parallel: <p>Text1<br>Text2</p>.
Why does the * + * match one of the <br>, but not the other? I can see in the DevTools now that you're right, but I don't get it.
Because there's a link on the second one. * + *
means: "each element that has a preceding element".
So <a></a><br>
matches, but just <br>
doesn't (text nodes aren't elements).
Furthermore, if the <br> has top-margin: 24 (and I can see that now, too), why doesn't it "push away" the "E-Mail"? Does the <br> coincide with the <p>, that is, is the top of the <br> equal to the top of the <p>?
The margin on an inline thing pushes away the whole line, not the element individually.
Reporter | ||
Comment 7•4 years ago
|
||
Ah, yes! Inline text is not an element, so the owl selector cannot match. That also means it has no own box and cannot push away the text before it. Thanks!
Is that behaviour under-specified or why do other browsers handle it differently? It's fascinating. :-)
Comment 8•4 years ago
|
||
Yeah, <br>
is relatively underspecified, I think: https://html.spec.whatwg.org/#the-br-element doesn't give a lot of details of what should happen in this case :)
I don't think CSS2 and others specify rendering of <br>
either, but I could be wrong.
Comment 9•4 years ago
|
||
Hmm, https://developer.mozilla.org/en-US/docs/Web/HTML/Element/br says...
You can set a margin on <br> elements themselves to increase the spacing between the lines of text in the block, but this is a bad practice — you should use the line-height property that was designed for that purpose.
But I wonder where that came from, as WebKit browsers don't seem to do this.
Comment 10•4 years ago
|
||
I filed a CSSWG issue, just to get some clarification... Probably we should change Firefox to match other browsers.
I think just removing the eReplaced
bit here should do: https://searchfox.org/mozilla-central/rev/2fd8ffcf087bc59a8e5c962965bbb7bf230bcd28/layout/generic/BRFrame.cpp#64, but this is really old code so probably a bit of a can of worms.
Also while I was digging for what other browsers do, I found an interesting comment in the chromium source that I thought was pretty funny:
// The whole class here is a hack to get <br> working, as long as we don't have
// support for CSS2 :before and :after pseudo elements.
Sure thing :-)
Comment 11•4 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3
(Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3
(normal.)
Updated•4 years ago
|
Updated•3 years ago
|
Updated•2 years ago
|
Comment 14•20 days ago
|
||
Description
•