You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Alan Baradlay noticed that we have an incompatibility between browsers in the case of a negative containing block and block-axis auto margins. Example:
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?
The text was updated successfully, but these errors were encountered:
Alan Baradlay noticed that we have an incompatibility between browsers in the case of a negative containing block and block-axis
auto
margins. Example: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?
The text was updated successfully, but these errors were encountered: