WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
242107
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
Details
View All
Add attachment
proposed patch, testcase, etc.
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
<
rdar://problem/96508147
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug