[CSSWG] Minutes Cupertino F2F 2023-07-18 Part III: CSS Grid [css-grid]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS Grid

  - RESOLVED: Accept edits [in this commit
              (Issue #3648: Distribute extra space into non-intrinsic
              tracks instead of going beyond growth limits)
  - RESOLVED: Keep working on a solution for this and take it back to
              the group (Issue #2873: Track Sizing Algorithm question)
      - There is compatibility concerns with a possible fix which will
          require investigation before a proposal is ready for the
          group to consider.
  - RESOLVED: Close no change and add tests (Issue #9075: Behavior of
              an item spanning several auto minimum tracks)
  - RESOLVED: Accept latest change [commit:
              (Issue #3565: minmax(auto,min-content) under a
              max-content constraint)


Agenda: https://github.com/w3c/csswg-drafts/projects/38

Scribe: emilio

CSS Grid

Extra space into non-intrinsic tracks instead of exceeding growth limits
  github: https://github.com/w3c/csswg-drafts/issues/3648

  <fantasai> https://github.com/w3c/csswg-drafts/commit/0cadf5297d3fd3584ca8a74ac0a86d6f28ab4ca2
  <fantasai> We're discussing this case:
  <fantasai> grid-template-columns: minmax(0, 100px) minmax(auto,
  <fantasai> item spanning both columns

  oriol: In the case we have an item with 2 tracks, one with an
         intrinsic min but fixed max, which spans also a track with
         both minmax
  oriol: instead of forcing the intrinsic track to grow beyond, it
         could be absorbed by the other track
  oriol: We have a resolution on this but edits missing
  oriol: yesterday we met and changed the spec
  oriol: it'd be great if you could review and agree with it
  oriol: The idea would be that we size the intrinsic tracks, then if
         all of them reach their limit then we check if there are
         other tracks that the item spans that could grow, and if so
         they'd absorb some contribution. If they also hit the limit
         then the intrinsic tracks grow beyond their limit
  oriol: so it's just inserting that middle step
  <fantasai> Edits to the specification:
  <TabAtkins> in the above case, the old spec would give as much space
              as it could do the second track (the intrinsic one),
              then if there's space leftover it would keep growing the
              intrinsic one past its max.
  <TabAtkins> now we'll first give space to the intrinsic track, then
              give space to the fixed track, *then* blow past the
              intrinsic track's limit only if we're *still* out of

  fantasai: [explains the problem in a whiteboard]
  astearns: For this example how are we choosing to fit the right col
  fantasai: Track sizing has different phases
  fantasai: The first one is the minimum
  fantasai: then the max
  fantasai: We're figuring out the minimum
  fantasai: and we know the min of the previous track is 0

  emilio: Does this require any extra layout passes? Explanation
          sounds like no
  fantasai: Right, no extra pass
  fantasai: When we distribute space for intrinsic sizes the algorithm
            distributing across multiple tracks goes through two phases
  fantasai: [explains the case with an extra auto column]

  dbaron: Some of what you were talking about reminds me about
          column-spanning cells in tables
  dbaron: In particular about what happens w/ multiple spanning things
          that are partially overlapping but that could distribute
          across multiple columns
  dbaron: Curious what you do here to avoid ...
  dbaron: I haven't heard talking about the order of the passes here
          or if you require multiple passes ...
  dbaron: or how you avoid to favor one track over other ...
  fantasai: There are three phases, but we don't want to favor one
            item over another
  fantasai: The algorithm tracks the current size and the planned
            increase separately
  fantasai: If I have multiple items spanning tracks
  fantasai: in order to prevent the ordering dependency we track the
            current size and then the planned increase independently
  fantasai: So if I have item 1 spanning cols 1 and 2 and item 2
            spanning columns 2 and 3
  fantasai: Item 1 is 100px and it divides evenly 50px into each
            track, so we track the planned increase is 50px each. item
            2 is 150px and it wants to distribute 75px per track
  fantasai: so we adjust the tracked increase on the columns
  <TabAtkins> (note that Elika is currently describing how the grid
              algorithm has worked for many years; we didn't change
  dbaron: I think the interesting case is if item 2 is smaller
  TabAtkins: It's not order-dependent for items within the same span
  dbaron: That's roughly the table solution

  iank: Conceptually you're tracking two sets of tracks, one if you
        don't need to blow out the limits and one if you don't
  fantasai: No, blowing out the limits happens per span
  fantasai: We only grow the content once and up to the limit. As we
            hit the limit we freeze those and keep growing
  fantasai: If we run out of space is when we unfreeze all the tracks
  fantasai: We propose to add a new phase to see if any of the fixed
            (ignored) tracks are able to grow
  iank: I think the way we impl this is tracking the items in (1) and
        (3) separately
  iank: need to think a bit more

  fantasai: One of the side-effects of this is that you're a lot less
            likely to blow out the limits, which seems good
  fantasai: The other side effect is that all of the tracks that have
            fixed sizes could end up different sizes. Like, a track
            with a fixed size could have a different size than the
            tracks that have an identical track-sizing function
            because of the spanning item
  fantasai: The width of the grid doesn't change because the extra
            space would be going into the other track
  fantasai: so we're not changing the total size of the grid

  dholbert: I wonder if an item spanning both auto-sized tracks and an
            item spanning the previous non-auto-sized track would end
            up growing the grid
  dholbert: I think right now the first item would inflate track (3)
            to 220px and not contribute to the first track
  dholbert: That is if a later auto track ends up getting inflated due
            to other items
  dholbert: but this change would also inflate the (1)
  fantasai: For that case if we got that right for (1) and (3) then
            (2) shouldn't be a problem

  <florian> pre-existing issue on sizing with multiple spanners:
  florian: I think this change doesn't introduce new problems but
           there are existing ones
  florian: I believe we have a problem for that case but this proposal
           doesn't make it worse
  dbaron: Based on my experience with tables you can't fix both the
          non-order-dependent and the minimal answer
  iank: It'd be still true that if there's an fr track we'd still
        stuff everything there?
  TabAtkins: Yes, if there's an fr track we don't do this intrinsic
             sizing step at all
  <TabAtkins> (rather, if an item spans an fr track it is completely
              skipped by these intrinsic steps)
  florian: I agree there's a conflict with minimizing the space and
           not taking the ordering dependence. Not sure I agree on
           which one to prioritize

  fantasai: But that's a great question dholbert because looking at
            the algorithm I'm not sure we got that correct
  astearns: Sounds like 1 way forward would be to accept this change
            and continue looking at the other cases
  fantasai: I think we're not introducing a problem but there might be
            a pre-existing problem
  florian: This is the one I pasted. If we find a break this week to
           revisit we should consider revisiting
  florian: I think it's addressable, but not sure how without breaking
           the non-ordered-dependency
  fantasai: I'm sure it's addressable with that because I figured it
            out with a friend a long time ago, it's in a pile of
  fantasai: So proposal is to accept edits and continue looking at the
            overlapping spans issue
  dbaron: [tries to convince florian of the ordering vs. optimal width
          conflict in the whiteboard]

  RESOLVED: Accept edits

Track Sizing Algorithm question
  github: https://github.com/w3c/csswg-drafts/issues/2873#issuecomment-402552212

  <fantasai> https://github.com/w3c/csswg-drafts/issues/2873#issuecomment-402552212
  fantasai: So we got an issue with a test-case with two columns, and
            two rows, one min-content, one auto
  fantasai: The results that they want is the first result, which
            makes sense
  fantasai: the one they get is the second
  fantasai: The question for the working group is do we think we can
            fix it and do we want to?
  fantasai: There's a compatibility concern

  fantasai: I can explain the result
  fantasai: The first step is satisfying the minimum
  fantasai: so min-content expands to minmax(min-content,
            min-content), auto expands to minmax(min-content,
  fantasai: There's extra magic but that's roughly what happens
  fantasai: so in the first pass we look at the items with span of 1
            and the first row becomes 1 em tall, the second becomes
            3em tall
  fantasai: then we look at the spanning item
  fantasai: and that's 10em, and since both have a min of min-content
            I'll distribute the extra space equally into two
  fantasai: so the change we'd have to make is if you have two columns
            that are min-content but one has a max-content maximum we
            prefer distributing into it
  fantasai: That's the technical direction, the question would be do
            we want to
  fantasai: Currently we grow all tracks as needed for min-content
            sizes, then another pass for max-content
  fantasai: we'd probably put a phase between min-content and
  fantasai: So do we want to pursue this or does it seem unreasonable?

  dholbert: Is max-content special here or would a 300px be treated
  dholbert: Same question for min-content
  fantasai: When we discussed this it seemed reasonable to try to fix,
            author expectation seems to make more sense
  fantasai: Main question is: is it web compatible

  florian: I think we should try, accounting with dholbert's nuanced
  florian: also cross-checking with the spanning issue discussed
  florian: but in terms of exploring yeah
  iank: My gut feeling is that it's hard to check whether this is web
        compatible, a bit of a webcompat black box
  fantasai: My guess is that authors that hit this change min-height
            or use fr
  iank: Yeah for this case it's clear but for other cases not so more
  astearns: iank, are you saying this is kind of a blackbox because we
            don't have a solution?
  iank: No, I just not have a good sense of how web compatible this
        would be
  emilio: This seems like the sort of thing you need to try and see if
          it impacts the rendering/webcompat
  emilio: and just see if you get bugs
  emilio: I don't want to argue against it, but as dholbert noted, I'm
          not sure min-content / max-content are special
  emilio: Maybe we want to generically distribute space to tracks with
          larger maximums
  fantasai: I'm not sure doing that would be compatible, we distribute
            evenly in a bunch of cases
  fantasai: min-content is special in the sense that is specifies a
            desire of making it as compact as possible
  dholbert: Not so sure, it's more about not wanting content clipped
  astearns: There are ways to fixing things to get what you want and
            by not doing anything we don't risk anything
  fantasai: The workaround has some side effects that might not be
            totally desirable

  astearns: So... strawpoll?
  (1) do nothing, (2) try to figure out a solution for this
  <florian> 2
  <astearns> 2
  <rachelandrew> 2
  <schenney> 2
  <argyle> 2
  <Sammy_Gill> 2
  <bramus> 2
  <miriam> 2
  <TabAtkins> abstain
  <oriol> 2, but not sure if possible due to compat
  <SebastianZ> 2
  <dholbert> 2 (weak preference)
  <fantasai> personal preference for 2
  <stewart> 2

  RESOLVED: Keep working on a solution for this and take it back to
            the group


Behavior of an item spanning several auto minimum tracks
  github: https://github.com/w3c/csswg-drafts/issues/9075
  scribe: bramus

  TabAtkins: Go look at the code issue for an example to make this
  <fantasai> live example: issue https://jsfiddle.net/4edu3v7z/1/
  TabAtkins: Core here is if you have an item spanning auto multiple
             tracks. We believe that chrome behavior has not updated
             to latest spec
  TabAtkins: In example here, every browser is basically wrong (have
             not tested safari)
  TabAtkins: In this example we got a grid item that is 20px min width
             and got a bunch of 25px floating children so its min
             content is 25px and its max content is 100px
  TabAtkins: Chrome ends up distributing that 20px
  TabAtkins: Firefox instead distributes the 25 evenly and the floats
             correctly fill the grid
  TabAtkins: afaik firefox is correct and following the intention
  TabAtkins: and chrome is not doing the second paragraph of the step
             that handles the space distribution for this case
  <astearns> https://usercontent.irccloud-cdn.com/file/qrtTBDuP/image.png
  TabAtkins: If you take this example and remove width 0 on body,
             chrome continues to do wrong thing. firefox does
             something else weird but maybe because of a difference
  <fantasai> modified testcase, removed the width:0 on body -
  TabAtkins: Our conclusion is spec is probably right, and browsers
             are wrong
  TabAtkins: If that is the case, then we can close the issue and the
             bugs need to be fixed

  iank: This case is explicitly testing the grid min size as min
  TabAtkins: Yeah, under a min-content or max content constraint.
             because grid is self (missed). you can trigger either
             behavior with width 0 on the body or (missed)
  TabAtkins: if you follow link to spec, chrome's behavior is
             explained by it only doing the first paragraph
  TabAtkins: I believe firefox does entire thing
  fantasai: And the max content bug in firefox seems to be related to
            next issue
  fantasai: where the spec has a bug

  astearns: Are the wpt for this?
  TabAtkins: Not yet, needs to fixed as well
  astearns: Unless reservations, seems like we need to write wpt and
            file bugs for differences
  TabAtkins: Yeah
  dholbert: Looks like safari matches chrome
  iank: (missed) complications?
  astearns: I expect that
  astearns: Proposed resolution is to close no change but put wpt in
            place and file browser issues

  RESOLVED: Close no change and add tests

minmax(auto,min-content) under a max-content constraint
  github: https://github.com/w3c/csswg-drafts/issues/3565

  <fantasai> See
  TabAtkins: If you look at very first comment, oriol has a test case
             here with some example and the wg decided earlier that
             chrome and edge are correct here.
  TabAtkins: Earlier we tried to implement that resolution in spec and
             we did it wrong, reverted, and did it again
  TabAtkins: Issue ended up being simpler than we thought
  <fantasai> Final fix was much simpler than we thought:
  TabAtkins: We believe only problem was in handling non spanning
             items in a min content constraint was
  TabAtkins: We were using the limited max content size
  TabAtkins: We should have been using limited min content size when
             resolving base sizes of auto tracks
  TabAtkins: Once we fixed that, algorithm made more sense in general
  TabAtkins: This text also dated back to 2016 which was early in grid
             spec text, so we believe this was a mistake we made early
  TabAtkins: This mistake was not copied over into spanning case but
             firefox behavior in previous issue was them doing the
             same thing in spanning case
  TabAtkins: If you do it in either case, it should be ok. we think
             spec text is ok now.

  astearns: You were nodding along?
  oriol: Yeah, we discussed yesterday and I think the current solution
         is the correct one
  astearns: Other comments?
  astearns: Proposed resolution to accept latest change as the
            solution to the earlier resolution
  astearns: Objections?

  RESOLVED: Accept latest change

Received on Sunday, 10 September 2023 15:10:44 UTC