Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-display] Can <br> / <wbr> elements be blockified? #7049

Open
bfgeek opened this issue Feb 15, 2022 · 9 comments
Open

[css-display] Can <br> / <wbr> elements be blockified? #7049

bfgeek opened this issue Feb 15, 2022 · 9 comments
Labels
css-display-3 Current Work

Comments

@bfgeek
Copy link

bfgeek commented Feb 15, 2022

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.

@bfgeek bfgeek added the css-display-3 Current Work label Feb 15, 2022
@bfgeek
Copy link
Author

bfgeek commented 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
Copy link
Member

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

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
Copy link
Member

dholbert commented Feb 15, 2022

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

Actually, Firefox isn't blockifying the br -- 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.

@dholbert
Copy link
Member

dholbert commented 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:

data:text/html,<div style="display: block; border: solid;"><br style="display:block"></div>

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 computed display of block when it's a direct child of a flex container, in IanK's testcases.

@dholbert
Copy link
Member

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-height impacts br height 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
Copy link
Member

@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
Copy link
Author

bfgeek commented 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:block etc 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
Copy link
Author

bfgeek commented Feb 16, 2022

and #4856.

@bfgeek
Copy link
Author

bfgeek commented Feb 16, 2022

(also thanks @dholbert for investigating - much appreciated).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-display-3 Current Work
Projects
None yet
Development

No branches or pull requests

2 participants