Repository navigation
[css-display] Can <br> / <wbr> elements be blockified? #7049
Description
Currently there is a discrepancy between engines Blink/WebKit/EdgeHTML, and Gecko.
Specifically when we have:
<div style="border: solid;">
<br style="display: block;">
</div>Blink/WebKit/EdgeHTML ignore the display on the <br>/<wbr> elements, and will always treat these elements as basically "text". Firefox I believe will treat these elements as "text" if the display: inline otherwise will generate an appropriate box. ( @dholbert is this analysis correct?)
This has larger effects, e.g.
<div style="display: flex; border: solid;">
<br>
</div>Here FF appears to be blockifying the <br>. Where as the others are treating it as "text" and surrounding it with an anonymous block. However it doesn't do this universally, e.g.
<div style="display: flex; border: solid; gap: 10px;">
a<br>b
</div>
<div style="display: flex; border: solid; gap: 10px;">
a<span></span>b
</div>If blockification was happening universally the two flexboxes above should render the same.
Activity
bfgeek commentedon Feb 15, 2022
There appears to be more complexity with the FF behaviour in that a
<br style="display: block;">doesn't act the same as a<div></div>. (margins appear to behave differently which is concerning).dholbert commentedon Feb 15, 2022
Yeah, Firefox has dedicated relatively-simple frame types for
<br>and<wbr>tags, to implement their special behavior:https://searchfox.org/mozilla-central/search?q=&path=brframe
WBRFrame was added relatively-recently (2019) in https://bugzilla.mozilla.org/show_bug.cgi?id=584141
BRFrame was added in nsBRFrame.cpp in 1998: https://searchfox.org/mozilla-central/rev/b2f664e4964dca4af82d45fb22321c10a27d5e6f/layout/generic/nsBRFrame.cpp#23
dholbert commentedon Feb 15, 2022
Actually,
Firefox isn't blockifying the-- we're surrounding it with an anonymous block just like other engines. It's just that the anonymous block ends up being 0-height for some reason.brdholbert commentedon Feb 15, 2022
Ah -- correction: actually, we're doing both. :) We're blockifying its display value and we're surrounding it with an anonymous block. (And other browsers also seem to do both, so we're all in agreement on that.)[1]
For us, the fact that it's blockified means (roughly) that the anonymous block doesn't create a line box -- it just sets up space for its block-level element, the br, which is itself block-level. So we render it as 0-height just as we do for this case where there's no flexbox involved:
I see Blink and WebKit both render this^ testcase with nonzero height, too, though.
So I think the real difference here is just the fact that this has 0-height in Firefox:
data:text/html,<div style="border: solid;"><br style="display:block"></div>[1] In Chrome and epiphany (gnome-web i.e. WebKit), the devtools show that the
<br>has a computeddisplayofblockwhen it's a direct child of a flex container, in IanK's testcases.dholbert commentedon Feb 15, 2022
This seems to have been reported as a Firefox bug in https://bugzilla.mozilla.org/show_bug.cgi?id=1547246 , though we haven't investigated in detail yet.
Possibly also related to an old bug from @Loirooriol about how
line-heightimpactsbrheight in Firefox, which is https://bugzilla.mozilla.org/show_bug.cgi?id=1374102 .(I suspect there are historical IE-compat reasons for Firefox's behavior here, but those probably aren't relevant at this point.)
dholbert commentedon Feb 15, 2022
@bfgeek let me know if this^ clears things up. In particular, I don't think there's any spec work needed on blockification here, since all browsers seem to do the same thing; we only have a difference on what height a standalone
<br style="display:block">has.bfgeek commentedon Feb 16, 2022
@dholbert - A little, I think I understand your behavior now a little more.
Yeah so for us - we effectively ignore the
display:blocketc on the<br>,<wbr>elements, and this is the main difference. I find our behaviour a little more intuitive here.Reading up on a few past issues brings up:
#610
#5749
Interestingly the reasoning in latter issue contradicts the rationale former issue (I think - from my very quick reading of them).
My sense is that treating the
<br>,<wbr>elements as close to "text" is desirable, and explains the various implementations apart from Firefox (happy to be wrong here, just my intuition for what is expected).bfgeek commentedon Feb 16, 2022
and #4856.
bfgeek commentedon Feb 16, 2022
(also thanks @dholbert for investigating - much appreciated).