Skip to content

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

Closed
@dholbert

Description

@dholbert

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions