[csswg-drafts] [css-flexbox][css-align][css-grid] abspos flex/grid item "align-self: auto behaves as start" spec-text is too vague

dholbert has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== [css-flexbox][css-align][css-grid] abspos flex/grid item 
"align-self: auto behaves as start" spec-text is too vague ==
The css-align spec (the canonical definition for `align-self`) is 
pretty unequivocal about how to handle `align-self:auto`. Quoting:
> The `auto` keyword computes to the computed value of `align-items` 
on the parent or `normal` if the box has no parent.
https://drafts.csswg.org/css-align/#propdef-align-self


 But, the flexbox & grid specs attempt to define some special-case 
behavior for this `auto` value on absolutely-positioned elements -- 
and IMO they're too vague about how/where that special case behavior 
is supposed to be triggered, and how broadly its effects spread.

The language I'm concerned about is here in the flexbox spec:
> For this purpose, a value of `align-self: auto` is treated 
identically to `start`.
https://drafts.csswg.org/css-flexbox-1/#abspos-items

...and here in the grid spec:
> For the purpose of calculating this static position, a value of 
`auto` for `align-self`/`justify-self` behaves as `start`.
https://drafts.csswg.org/css-grid-1/#static-position

Superficially, the phrase "a value of" is too vague.  (Is that "a 
*specified* value"? "a *computed* value"? something in between?)  And 
of course, "behaves as" is vague too.

I have these specific questions/concerns:
1) Are the flex/grid specs are trying to *redefine* the computed value
 of `align-self:auto` for these abspos elements?  Or is 
`align-self:auto` still intended to *compute* the way that css-align 
defines it (to the parent's computed `align-items`) and then its 
computed value (e.g. `center` if the parent has `align-items:center`) 
should somehow produce different layout behavior than it normally 
would?

2) If the intent for (1) is the latter (i.e. if `auto` computes away 
but then ends up somehow producing different results in layout), how 
is the different behavior intended to be triggered?  Layout uses 
computed/used values of css properties -- so if `auto` gets computed 
away, then I don't see how layout would be able to realize that it 
needs to apply this special-case behavior.  Maybe e.g. when `auto` 
computes to `center`, it's expected to really compute to a special 
`center-which-really-came-from-auto` value, which is expected to 
behave just like `center` except in this special abspos case?

3) It's not clear to me what should happen here when an 
`align-self:auto` value is *inherited* to an abspos element.  For 
example: suppose an abspos element inside of a flex container has 
`align-self:inherit`, and its parent has `align-self:auto`, and its 
grandparent has `align-items:center`.  I'm pretty sure this abspos 
element should end up with a computed `align-self` of `center`, BUT: 
is that really `center`, or is it the `center-which-came-from-auto` 
scenario discussed above in (2)?  (This matters for layout -- if we 
inherit the pure `center` value, the static position would be 
center-aligned.  But if we inherit some magically tainted 
`center-which-came-from-auto` value, then the static position would be
 start-aligned.)

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/440 using your GitHub 
account

Received on Saturday, 3 September 2016 17:49:35 UTC