W3C home > Mailing lists > Public > www-style@w3.org > May 2012

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 09 May 2012 02:17:40 -0700
Message-ID: <4FAA3634.8080207@inkedblade.net>
To: "L. David Baron" <dbaron@dbaron.org>
CC: www-style@w3.org
On 05/08/2012 02:11 AM, L. David Baron 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.)

Fixed grammar to not allow it as a standalone value.
I don't have a particular attachment to this method of disambiguating
true vs. safe alignment, but I wanted to point out that we might need
one and one possible way of handling the distinction.

> 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:
>   * 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.

Ok, I've added child-justify to both tables now to prevent this confusion.

> 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

child-align primarily exists to have something to map flex-align to;
otherwise I wouldn't have it.

>     (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.

It's meaningless for flexbox, but it applies in grid and in block layout.

>   * 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?)

See Tab's response: there's only ever a single grid item in a grid cell,
and rows are always inline.

> 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)

Seem to be missing something so not removing. :)

>   * '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

Can't remove because Flexbox wants it.

>   * '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'

I'm happy to remove this one, but if we have child-align applying
to grid items, we'll want a parallel child-justify property.

Received on Wednesday, 9 May 2012 09:18:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:16 UTC