Open Bug 1621387 Opened 4 years ago Updated 20 days ago

Margin on <br> affects layout, unlike on other browsers

Categories

(Core :: Layout: Block and Inline, defect, P3)

defect

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.

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.

Component: Untriaged → Layout: Text and Fonts
Product: Firefox → Core
Summary: Spurious leading line in <p> → Additional margin applied to paragraph only by Firefox
Version: 74 Branch → Trunk

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>
Component: Layout: Text and Fonts → Layout: Block and Inline
Summary: Additional margin applied to paragraph only by Firefox → Margin on <br> affects layout, unlike on other browsers

(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?

Status: UNCONFIRMED → NEW
Ever confirmed: true

That one doesn't match the * + * rule.

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>?

(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.

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. :-)

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.

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.

Priority: -- → P3

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 :-)

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.)

Severity: normal → S3
Webcompat Priority: --- → ?
Webcompat Priority: ? → P3
Blocks: 1835391
Duplicate of this bug: 1352400
Duplicate of this bug: 1883280
See Also: → 1835391
See Also: 1835391
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: