Re: [CSS Box Alignment] Comments on CSS Box Alignment proposal

On Tue, May 8, 2012 at 11:11 AM, L. David Baron <dbaron@dbaron.org> wrote:
> A few comments on
> http://fantasai.inkedblade.net/style/specs/css3-align/ follow:
>
> I don't think using 'true' as a property value works.  Even though
> you don't mean it as a boolean, it looks like one.  Though it might
> work if it were only allowed in combination with the other keywords.
> (In fact, I'm not sure what it means for it to be used alone; it
> seems like it's perhaps equivalent to 'true start' or 'true before',
> though that's not clear.)

Hmm, I agree.  Using 'true' is kinda confusing.  Not sure what better
keyword to use, though.


> There also seems to be a bit of confusion (e.g., between the tables
> in section 2, Overview of Alignment Properties) as to whether, for
> the inline/main axis alignment, there is one property for default
> alignment of children and alignment of contents, or whether there
> are two separate ones:

I think that's just because we're almost certain to name the pairs of
property (particularly the default-alignment properties) with the same
pattern, so adding a sixth column to the "alternate name" table would
be largely information-free.


>  * For a start, the "sets default 'box-align' of children" should
>   probably say "sets default 'box-justify'/'box-align' of
>   children".
>
>  * Additionally, though, the 'child-justify' property is mentioned in
>   the table but not anywhere else.

I also think this is a mistake.  I think fantasai's justification is
just that it's not yet used by any spec, but I think it looks really
confusing.


> However, this leads me to a set of closely related broader issues:
>
>  * It seems to me that in the case where the parent lays out its
>   children (and I mean children, not descendants) in one dimension,
>   i.e., everything except grid, then:
>
>   (a) there's no point distinguishing between 'content-align' and
>   'child-align' since there's only one child at any given point in
>   the secondary direction

Nope - in Flexbox 'content-align' is what we currently call
'flex-line-pack', while 'child-align' is what we currently call
'flex-align'.  ('box-align' is 'flex-item-align'.)


>   (b) the 'box-justify' property is meaningless since the children
>   in the primary direction have to be aligned together (so I'm
>   confused by the checkmark in the 'box-justify'/Block cell)
>   *unless* there are external constraints on the space allocated to
>   children (like constraints from other rows for the horizontal
>   space given to cells within a table row) that don't (like they do
>   for tables) actually change the size of the cells.

Hm, it looks like fantasai defined the primary axis of Block Layout to
be the inline-axis.  Not sure if that's valid - it's opposite that of
a column flexbox, which should look a lot like Block Layout by
default.


>  * I'm confused about whichever of 'grid-row-align' and
>   'grid-column-align' is in the block direction (I'm not sure this
>   is fixed as the table suggests) is supposed to work when there is
>   more than one grid item in a cell.  In particular, aren't the
>   items going to be laid out as blocks in one dimension?  If so,
>   how can they be *individually* aligned in that dimension?  (And
>   isn't the ability to have multiple items in a cell the only
>   reason that grid doesn't behave like tables (resizing the items)
>   and avoid case (b) in the point above?)

Grid is defined to always pay attention to writing mode, such that the
rows are along the inline axis and the columns are along the block
axis.

Grid Items always overlap if they're positioned in the same cells.
You're probably thinking about the older Template Layout, where
putting multiple items in the same cell would make them flow together.
 I think Grid is intending to handle that sort of thing with Regions
flowed into ::cell pseudos.


> These lead me to believe (if I've thought this through correctly,
> which I'm not particularly confident of) that the six properties
> given in the table should be collapsed into three:
>
>  * 'box-justify' should be removed since you can't align an element
>   in the direction in which its parent lays out children (despite
>   that grid claims to have such a property without actually saying
>   how it works -- unless I'm missing something here, which I
>   certainly could be)

You are.  ^_^  See above.

>  * 'child-align' should be removed since there's no reason to
>   separate it from 'content-align': if an element's children
>   support 'box-align' or auto margins then 'content-align' is
>   perfectly fine to use as the default rather than needing a
>   separate property for this

The two are quite different, and Flexbox absolutely needs both of
them, since it already has three different cross-axis alignment
properties.


>  * 'child-justify' should likewise be removed since it sets the
>   default for 'box-justify' on children, and I'm proposing removing
>   'box-justify', and for the same reasons as 'child-align'

As stated above, box-justify isn't useless.

~TJ

Received on Tuesday, 8 May 2012 09:52:33 UTC