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

(12/07/12 0:33), Alex Mogilevsky wrote:
> It is possible to define it that way, it was that way at some point.
> However there are some non-trivial details to be defined, the
> position in the middle of the space seems as random as any other, it
> is more complicated to implement, all for the benefit of something
> that nobody could come up with a sensible use case for.

Do we have use cases for the 'auto' location of a absolutely positioned
flex item then? And what are they? I mean, why can't we just say there
are no placeholders and the 'auto' location is that of the flex container?

This is alternative proposal A.

> There are more details to be defined if we were taking this route.
> What happens if there are multiple positioned items with
> placeholders?

Here is a concrete proposal B:

Add the following prose to each of the description of 'space-between'
and 'space-around':

  | In the above description, flex items generated by placeholders left
  | by absolutely positioned children of the flex container are ignored
  | and spaces between non-placeholder flex items are added as if half
  | of the space is added to both non-placeholder flex items. Note:
  | This means, for example, a placeholder in between two flex items
  | would be located exactly in the middle of the margin edges.

Examples ('space-between'):

A-|-B--C

A-||-B--C

|A--B--C|

where '|' stands for placeholders and '-' stands for the "half spaces"
added.

> What happens if the position element is at the end of a line in
> multiline flexbox – which line does it go to?

The previous line. Because the prose takes an effect after flex items in
a flex line is determined, and a flex item of zero flex basis would
always goes to the previous line.

I don't think it is hard to define, but I don't how hard it is in terms
of implementation.

> We have chosen the simplest approach in the case where other
> approaches involved non-zero additional complexity and no
> demonstrated benefits.

With the "no change" proposal being C. My preference is

  B > A > C

I am curious what Web developers would prefer though, in particular A vs. C.



Cheers,
Kenny

Received on Wednesday, 18 July 2012 14:45:21 UTC