-
Notifications
You must be signed in to change notification settings - Fork 708
[css-display] Can <br> / <wbr> elements be blockified? #7049
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
Comments
There appears to be more complexity with the FF behaviour in that a |
Yeah, Firefox has dedicated relatively-simple frame types for WBRFrame was added relatively-recently (2019) in https://bugzilla.mozilla.org/show_bug.cgi?id=584141 |
Actually, |
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: [1] In Chrome and epiphany (gnome-web i.e. WebKit), the devtools show that the |
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 (I suspect there are historical IE-compat reasons for Firefox's behavior here, but those probably aren't relevant at this point.) |
@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 |
@dholbert - A little, I think I understand your behavior now a little more. Yeah so for us - we effectively ignore the Reading up on a few past issues brings up: 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 |
and #4856. |
(also thanks @dholbert for investigating - much appreciated). |
Currently there is a discrepancy between engines Blink/WebKit/EdgeHTML, and Gecko.
Specifically when we have:
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 thedisplay: inline
otherwise will generate an appropriate box. ( @dholbert is this analysis correct?)This has larger effects, e.g.
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.If blockification was happening universally the two flexboxes above should render the same.
The text was updated successfully, but these errors were encountered: