Skip to content

[css-grid] span=1 and span>1 use different size contribution to 'auto' min-sizing #500

Closed

Description

@MatsPalmgren

https://drafts.csswg.org/css-grid/#algo-content
Step 1 : "For auto minimums" says:
If the track has an auto min track sizing function and the grid container is being sized under a min/max-content constraint, set the track’s base size to the maximum of its items’ min/max-content contributions, respectively.

In Step 2 : "For intrinsic minimums" there is no such special handling for 'auto' min-sizing.

It seems a bit odd that span=1 and span>1 items should contribute different sizes to 'auto' tracks.
Is this an oversight and that the above paragraph also applies to span>1 items for 'auto' min-sizing tracks?

Activity

  1. tabatkins commented on Sep 20, 2016

    @tabatkins
    Member

    I think this is handled by steps 2.2 and 2.3 there? We apparently thought it was better to split the auto-handling separately for the two cases in step 2, while step 1 handles it in one spot.

  2. fantasai commented on Sep 20, 2016

    @fantasai
    Collaborator

    Marking invalid; please re-open if this is incorrect. :)

  3. MatsPalmgren commented on Sep 20, 2016

    @MatsPalmgren
    Author

    2.2 is labeled "For content-based minimums" which to me means
    'min/max-content', so I find the label misleading (because the spec
    text under it now also includes 'auto').

    2.3 is labeled "For max-content minimums" which to me means
    'max-content', so I find the label misleading.

    Just to make sure I understand the span>1 handling of 'auto' correctly:
    2.1 "For intrinsic minimums", clearly includes 'auto' (unconditionally),
    so this means that an item that spans an 'auto' track first contributes
    its min-size contribution under 2.1, then also (one of) its min/max-content
    contribution under 2.2/2.3 (under intrinsic sizing).
    So the net effect for 'auto' in 2.1 - 2.3 is slightly different from
    the span=1 case due to the "Otherwise" there, is that intentional?

  4. MatsPalmgren commented on Sep 20, 2016

    @MatsPalmgren
    Author

    After thinking some more about the 'auto' case, I suspect that applying
    both its min-sizing (2.1) and min/max-content (2.2/2.3) contributions
    is probably correct for the span>1 case. We apply both contributions
    for 'min-content' and 'max-content' too in the span>1 case, but not
    in the span=1 case. So if the goal of these changes were "make 'auto'
    min track sizes behave as 'min(max)-content' when sizing under
    a min(max)-content constraint" then the current text looks correct.

    If so, I think it would be equivalent to stating upfront that "if sizing under
    a min(max)-content constraint then treat an 'auto' min track sizing
    as a 'min(max)-content' track min sizing in the following rules"
    (for any span).

  5. fantasai commented on Sep 21, 2016

    @fantasai
    Collaborator

    I don't think there's an intentional difference... what is the difference you're noticing?

  6. MatsPalmgren commented on Sep 25, 2016

    @MatsPalmgren
    Author

    I don't think I can explain it better than I did in the last comment.

    Anyway, the problem I originally reported doesn't exist so I'm fine with
    the current spec text in that regard.

  7. MatsPalmgren commented on Sep 25, 2016

    @MatsPalmgren
    Author

    You might want to fix the editorial issue with the labels I mentioned above though...

  8. fantasai commented on Feb 2, 2017

    @fantasai
    Collaborator

    Tab and I looked over this again and decided to handle it as you suggested in #500 (comment) ... in particular as 2.2 seems to have left out max-content constraint handling for auto, even though max-content is handled there, and that seems like an error.

  9. fantasai commented on Feb 2, 2017

    @fantasai
    Collaborator

    Fixed in d8a33b9 . Please let us know if this seems correct now. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions