[css3-flexbox] absolutely positioned flex item should not have side effect on space distribution from Kang-Hao (Kenny) Lu on 2012-07-18 (www-style@w3.org from July 2012) (original) (raw)

(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