- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Fri, 10 Jan 2025 22:16:30 +0000
- To: public-css-archive@w3.org
fantasai has just created a new issue for https://github.com/w3c/csswg-drafts: == [CSS2][css-position-3] Negative containing blocks and `auto` margins == [CSS2][css-position-3] Negative containing blocks and `auto` margins 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](https://www.w3.org/TR/CSS2/visudet.html#abs-non-replaced-height), 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](https://drafts.csswg.org/css-position-3/#resolving-insets). Then, auto margins get an equal negative size, centering the element on the IMCB in [section 4.2](https://drafts.csswg.org/css-position-3/#abspos-margins>). (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? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11478 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 10 January 2025 22:16:31 UTC