Re: [css3-flexbox] absolutely positioned flex item should not have side effect on space distribution

I am a bit confused here. Let me ask some questions before I get too

(12/07/24 15:17), Morten Stenshorne wrote:
> fantasai <> writes:
>> So far we've had Kang-hao and Brad Kemper weigh in on
>>   B > A > C
>> From implementer's perspective, I suspect it would be more like
>>   C > B > A
> That's about right. :) What I read in the spec about abspos, back when I
> did the initial flexbox implementation, looked sane. That was C.
> This is a corner case (well, that's what I'm thinking anyway, so I
> cannot provide any use cases), so keeping it easy to spec and implement
> would be nice. C is similar to how abspos behaves inside of table,
> table-row-group and table-row (anonymous table structural boxes are
> inserted).

s/anonymous table structural boxes/'inline' placeholder/?

> Allowing abspos boxes to live inside of a non-container sounds
> unpleasant (A / B), not only on the implementation side, but it also
> requires you to spec a lot of things. Cross position? Is it stretched?
> Flexed? Order?

So now the "no change" proposal C is having this problem (issue 17[1] -
Does 'order' affect abspos placeholders?). B certainly has this problem
too. Are you actually referring to (B / C), which have the concept of


> It looks like B attempts to give the element "the position an element
> would have had in the normal flow" [1]. But then I think it should
> rather say that the static position is identical to that of the next
> flex item (or, if there is no next, then at main-end? Unless there's no
> preceding flex item, in which case we could pick main-start?). 

That'll be another proposal, yes.

> And then some justify-content stuff. That was the main axis position. 
> What about cross axis position? Honor align-items/align-self
> (obviously in a way that doesn't affect the cross size of the flexbox
> or its lines)?
> My preferences:
> C > world-wide coffee ban > B ~ A
> A is simpler than B, but behavior A almost sounds like a bug report. :)
> [1]


Received on Tuesday, 24 July 2012 09:23:13 UTC