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

[CSS2][css-position-3] Negative containing blocks and auto margins #11478

Open
fantasai opened this issue Jan 10, 2025 · 3 comments
Open

[CSS2][css-position-3] Negative containing blocks and auto margins #11478

fantasai opened this issue Jan 10, 2025 · 3 comments
Labels

Comments

@fantasai
Copy link
Collaborator

fantasai commented Jan 10, 2025

Alan Baradlay noticed that we have an incompatibility between browsers in the case of a negative containing block and block-axis auto margins. Example:

<div style="border: solid; width: 100px; height: 100px; position: relative">
  <div style="position: absolute; border: solid orange 10px; margin: auto; inset: 90px"></div>
</div>

This creates a 20px orange abspos inside a 100x100 containing block, with auto margins on all sides.

But the insets are 90px, which means the inset-modified containing block would be a negative size.

CSS2 defines the vertical-axis positioning rules in terms of an equation in section 10.6.4, which results in this box being centered.

Position 3 defines a slightly different behavior. First, the negative-size IMCB is adjusted to zero-size by altering the weaker inset in section 3.5.1. Then, auto margins get an equal negative size, centering the element on the IMCB in section 4.2. (In the inline axis the spec instead start-aligns the item into the IMCB, presumably to match the asymmetry of CSS2.)

WebKit currently exhibits the CSS2 behavior, while Firefox and Chrome exhibit the css-position-3 behavior.

The difference between the two specs was not intentional. What should we do?

@Loirooriol
Copy link
Contributor

Loirooriol commented Jan 10, 2025

WebKit currently exhibits the CSS2 behavior, while Firefox and Chrome exhibit the css-position-3 behavior.

I'm seeing something different:

Webkit Firefox Chrome Servo

@bfgeek
Copy link

bfgeek commented Jan 13, 2025

The difference in axis behaviour in Blink is due to the (compat required) difference in auto margins. See:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/absolute_utils.cc;l=276-279?q=is_block_direction&ss=chromium

(In the block-direction of the child auto-margins are "unsafe", in the inline-direction they are "safe").
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=13386

Gecko & Blink match behaviour in the above case, Firefox appears to change its behaviour based on if the width/height & min-width/min-height are auto. E.g.
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=13387

Safari starts to match Servo in the above case.

Blink is consistent in behaviour across the different cases.

@Loirooriol
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants