W3C home > Mailing lists > Public > www-style@w3.org > November 2015

[css-align] Should 'left'/'right' compute to 'start' also for 'align|justify-items'?

From: Mats Palmgren <mats@mozilla.com>
Date: Sat, 21 Nov 2015 00:44:21 +0100
To: www-style@w3.org
Cc: Daniel Holbert <dholbert@mozilla.com>
Message-ID: <564FB055.5050700@mozilla.com>
Daniel and I disagree about what the spec intends for
align|justify-items:left/right, can someone please clarify?

The relevant spec sections here (I think) are:
https://drafts.csswg.org/css-align-3/#valdef-self-position-left
"left (self, content)
     Aligns the alignment subject to be flush with the alignment
     container's line-left edge. If the property's axis is not parallel
     with the inline axis, this value computes to start."

and:
https://drafts.csswg.org/css-align-3/#align-items-property
"This property specifies the default 'align-self' for all of the boxes..."
"'auto' ..."
"Other values have no special handling and are merely passed to align-self."

As I read the spec, left/right on align|justify-items compute to
themselves and are copied as is to a child with align|justify-self:auto
and only then is it mapped to start (for the property that corresponds
to the block-axis).  I think the "no special handling" in the last
sentence above supports this view.

Daniel thinks that left/right should compute to start also on
align|justify-items itself (for the property that corresponds to
the block-axis) before it is copied to any align|justify-self:auto
children.  The first spec quote above supports this view.

But that seems weird to me that we should try to map the value twice,
first on the parent for *-items, and then again after it's copied
to *-self on the child.

I think the two views can give different results for example when
a grid item is also a flex container.

Either way, it would be good if the spec could say explicitly
how left/right should be computed for align|justify-items.

Thanks,
Mats
Received on Friday, 20 November 2015 23:44:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:29 UTC