New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 661662 link

Starred by 4 users

Issue metadata

Status: WontFix
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Blink incorrectly applies parent's "align-items" to abspos flex children

Project Member Reported by dholb...@gmail.com, Nov 2 2016

Issue description

Version: Chrome 56.0.2906.0 dev (64-bit)
OS: Ubuntu 16.10

What steps will reproduce the problem?
(1) Load this testcase: https://jsfiddle.net/6c9xz31x/

What is the expected output?
 * In both flex containers, the blue (abspos) child should be at the container's top left corner.  (It shouldn't be influenced by the second container's "align-items" value.)

What do you see instead?
 * The blue box is at the bottom in the second container. It's incorrectly being influenced by "align-items" on the parent.

Please use labels and text to provide additional information.
This bug is about how "align-self:auto" (the default value) is handled, for abspos children. The CSS Box Alignment spec says this about "align-self":
> The 'auto' keyword is interpreted as 'normal' if the box
> is absolutely positioned or has no parent, and as the
> computed value of 'align-items' on the parent otherwise.
https://drafts.csswg.org/css-align/#valdef-align-self-auto

Chrome isn't honoring the first half of that sentence -- the special behavior for abspos children.  (I think the spec might've changed since this code was last touched, too; not sure.)

(The 'normal' keyword is explained right afterwards, but in this case it's supposed to behave like "the fallback for stretch", which is "flex-start". https://drafts.csswg.org/css-align/#align-abspos-static. In any case, it should behave the same regardless of the parent's "align-items" value.)

Edge has the same behavior as Chrome, FWIW.  Firefox Nightly (where I've just implemented the latest spec) gives "expected output".
 

Comment 1 by dholb...@gmail.com, Nov 2 2016

Components: Blink>Layout>Flexbox

Comment 2 by dholb...@gmail.com, Nov 2 2016

Cc: tabatkins@chromium.org
A few spec-change links, for reference:

(1) The flexbox spec change that required "expected output" here was in Dec 2015:
https://hg.csswg.org/drafts/rev/97df1bd008c1
That change added this text:
> "For this purpose [determining static position], a value of 'align-self: auto' is treated identically to 'align-self/start'.

(2) The css-align spec was later clarified to harmonize with that, here:
https://hg.csswg.org/drafts/rev/25034b1448a3
That added the spec text I quoted in my initial comment here. (about interpreting 'auto' as 'normal')

So at this point, both the flexbox & the css-align specs require the "Expected output" that I described here.

(3) That ^ css-align change was to address https://github.com/w3c/csswg-drafts/issues/440 -- and in a comment there, fantasai says the "Expected output" here is definitely what the spec editors were intending:
> The intention is that absolutely-positioned items never take their parent's align/justify-items value

Comment 3 by e...@chromium.org, Nov 4 2016

Labels: -Pri-3 Pri-2
Owner: cbiesin...@chromium.org
Status: Assigned (was: Untriaged)
Thanks, csswg, for changing the spec in a way that's incompatible with all implementations at the time of writing.

Comment 5 by dholb...@gmail.com, Feb 24 2017

Per "However!" in https://github.com/w3c/csswg-drafts/issues/440#issuecomment-280459999 , it looks like the spec will soon be changing again, such that Chrome's behavior here will be correct now.
Status: WontFix (was: Assigned)
Spec has changed and our behavior is now correct.

Sign in to add a comment