NEW242107
margin collapsing, zero-height line box containing margin-inline
https://bugs.webkit.org/show_bug.cgi?id=242107
Summary margin collapsing, zero-height line box containing margin-inline
2843035794
Reported 2022-06-29 03:53:52 PDT
Created attachment 460539 [details] the two file only change margin-left Some grammar in webkit and chrome have different display . When use margin-left:5px. Chrome and webkit have different display. Then I see the https://developer.mozilla.org/en-US/docs/Web/CSS/white-space,I think it can not display like br. WebKitGTK version is 2.36.3
Attachments
the two file only change margin-left (1.13 KB, application/x-zip-compressed)
2022-06-29 03:53 PDT, 2843035794
no flags
Sam Sneddon [:gsnedders]
Comment 1 2022-07-04 21:55:58 PDT
This is really just: <div><span style="margin-left: 5px;"></span></div> <div style="margin-top: 20px;">hello</div> And the lack of interop is whether the margin of the second div collapses through the first zero-height div into the body. Relevantly: > Line boxes that contain no text, no preserved white space, no inline elements with non-zero margins, padding, or borders, and no other in-flow content (such as images, inline blocks or inline tables), and do not end with a preserved newline must be treated as zero-height line boxes for the purposes of determining the positions of any elements inside of them, and must be treated as not existing for any other purpose. This implies the line box from the span is just a zero-height line box and it does exist for all purposes (because it contains an inline element with a non-zero margin). This then means that the margins cannot be adjoining (as there is a zero-height line box separating them). We do seem to match Firefox here, which to me makes me wonder if this was a deliberate change in LayoutNG for Chrome… It might be worth reporting this to Chrome, to see if they believe this is a deliberate change in behaviour and how they justify this v. the spec (or if they've filed an issue I can't find).
alan
Comment 2 2022-07-05 09:47:58 PDT
(In reply to Sam Sneddon [:gsnedders] from comment #1) > This is really just: > > <div><span style="margin-left: 5px;"></span></div> > <div style="margin-top: 20px;">hello</div> > > And the lack of interop is whether the margin of the second div collapses > through the first zero-height div into the body. > > Relevantly: > > > Line boxes that contain no text, no preserved white space, no inline elements with non-zero margins, padding, or borders, and no other in-flow content (such as images, inline blocks or inline tables), and do not end with a preserved newline must be treated as zero-height line boxes for the purposes of determining the positions of any elements inside of them, and must be treated as not existing for any other purpose. > > This implies the line box from the span is just a zero-height line box and > it does exist for all purposes (because it contains an inline element with a > non-zero margin). This then means that the margins cannot be adjoining (as > there is a zero-height line box separating them). > > We do seem to match Firefox here, which to me makes me wonder if this was a > deliberate change in LayoutNG for Chrome… > > It might be worth reporting this to Chrome, to see if they believe this is a > deliberate change in behaviour and how they justify this v. the spec (or if > they've filed an issue I can't find). I'd think it's just an "inline box" specific bug on their side as if you replace the inline box with a regular (non-inline box) inline level box, vertical margins show as expected.
Radar WebKit Bug Importer
Comment 3 2022-07-06 03:54:12 PDT
Note You need to log in before you can comment on or make changes to this bug.