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.

Sign up for GitHub

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

Jump to bottom

[css2] Margins shouldn't collapse through replaced element #9006

Open
Loirooriol opened this issue Jun 26, 2023 · 5 comments
Open

[css2] Margins shouldn't collapse through replaced element #9006

Loirooriol opened this issue Jun 26, 2023 · 5 comments
Labels
CSS2

Comments

@Loirooriol
Copy link
Contributor

Loirooriol commented Jun 26, 2023 •
edited 

<!DOCTYPE html>
aaa
<canvas style="display: block; margin: 50px 0; height: 0px; min-height: 0"></canvas>
bbb

No browser lets the top and bottom margins of the replaced element to collapse through it.
The conditions are: https://drafts.csswg.org/css2/#collapsing-margins

  • both belong to in-flow block-level boxes that participate in the same block formatting context
  • no line boxes, no clearance, no padding and no border separate them
  • top and bottom margins of a box that does not establish a new block formatting context and that has zero computed min-height, zero or auto computed height, and no in-flow children

The interior of replaced elements is outside the scope of CSS, so I guess UAs might establish an independent formatting context if they want. But probably this shouldn't be left up to the UAs, the spec should explicitly handle replaced elements.
@dbaron
Copy link
Member

dbaron commented Jun 26, 2023

Agreed. I'd perhaps add an "and is not a replaced element" after "does not establish a new block formatting context".

@Loirooriol
Copy link
Contributor Author

Or "top and bottom margins of a non-replaced box that does not establish a new block formatting"

@bfgeek
Copy link

bfgeek commented Jun 26, 2023

Arguably replaced elements establish their own formatting contexts - also the text should likely be just "independent formatting context" instead of "block formatting context"

@Loirooriol
Copy link
Contributor Author

the text should likely be just "independent formatting context"

Sure but CSS2 doesn't have that term. Just like when it says "vertical margins" and we understand "block margins", when it says "new block formatting context" we should treat it as "independent formatting context".

Arguably replaced elements establish their own formatting contexts

Not opposed to that, but other parts of CSS2 don't make that assumption and handle replaced elements explicilty, e.g. https://drafts.csswg.org/css2/#floats

The border box of a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context

@Loirooriol
Copy link
Contributor Author

OK it's already on Display 3: https://drafts.csswg.org/css-display-3/#replaced-element

Replaced elements always establish an independent formatting context.

CSS2 can still be clarified, but not sure if it's worth it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
CSS2
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dbaron @bfgeek @Loirooriol