[CSSWG] Minutes Cupertino F2F 2023-07-18 Part IV: Flexbox, Grid Continued, Box [css-flexbox] [css-grid] [css-box]

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


  - RESOLVED: Take existing algorithm, mark it as informative, and
              explain why that is (Issue #8884: Intrinsic main size
              algorithm for row flexboxes not web compatible)
  - RESOLVED: Spec what chrome has implemented in canary currently
              (Issue #8884)
  - TabAtkins and fantasai will look into the compat findings for
      further iterative improvements to the algorithm.

CSS Grid (Continued)

  - RESOLVED: Close no change. Spec is what we intended. Action to
              file bugs on browsers and create WPTs (Issue #8966:
              Honoring the specified width/height of a subgrid)


  - RESOLVED: margin-trim doesn't apply to floats (by default), and
              we'll explore the interaction in the future (Issue
              #8547: Use cases for margin-trim on floats)


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

Scribe: bramus


Intrinsic main size algorithm for row flexboxes not web compatible
  github: https://github.com/w3c/csswg-drafts/issues/8884

  iank: Currently all the implementations have same interop algorithm
        for single line row flexboxes
  iank: This however does not take a bunch of stuff like flex basis
        into account
  iank: Effort by Tab and Elika to specify an algorithm that would be
        compatible that takes all that sufficiently into account
  iank: Chrome has been experimenting with this algorithm
  iank: and tried to ship on canary. tldr is that currently spec
        algorithm is not web compatible
  iank: We added test cases for sites that we know that we broke
  iank: Impact was very very wide
  iank: We broke a lot of stuff, like gmail
  iank: We are likely a lot or compat constrained
  iank: Have a proposed algo, that we have been running in canary and
        we have not broken anything (yet)
  iank: I think this is a floor for us to start

  TabAtkins: We've been avoiding looking at this issue for a while
  TabAtkins: I need to refresh my brain on why this case gets 300px
             wide in the spec
  iank: Keep in mind that is only 1 of the issues that we ran into,
        there is at least 5 different issues that we run into that are
        subtly different
  iank: We tried a variation where we tried to fix a few things when
        the flex fraction is ??? its not gonna work. We are very
        compat constrained
  iank: We think that we can go for a super relative small incremental
        fix, that fill fix the ??? case that will fix some flex basis
        being a definite thing.
  iank: Roughly it is if the flex base size is greater than the main
        contribution and it can't shrink then use that. Same for
        growing and same for max contributions.
  iank: For other things we are way more compat constrained
  iank: We broke everything

  fantasai: There are two halves to intrinsic size computation. min
            and max content sizing
  fantasai: These are different in a bunch of cases. did we break both
            of them?
  iank: Yeah, both
  iank: got reports for both
  fantasai: The min content stuff we were trying to make it there was
            no overflow within the items. So the ??? was larger than
            the naive version for partly that reason
  fantasai: The max content one we get a size that is bigger but also
            don't get the max content size if you do the current
            behavior, which does not seem like it satisfies the use
  iank: Need to check, but we also broke the max content size. People
        have relied on current behavior because we have good interop.
        We think we can get away with respecting flex-basis as
        described because that is very broken
  iank: is running on canary, so we might identify issues
  fantasai: Seems unfortunate, because we can't size a flexbox to fit
            its content if not following the spec algo
  fantasai: like you get a random size in implementations right now

  astearns: Proposed change is to revert the algorithm?
  fantasai: This was original algorithm that was never implemented,
            so nothing to revert to
  iank: We tried to implement to see if its compatible
  astearns: How did we manage to get to interop?
  fantasai: Were doing a much more naive implementation. If you take a
            flex-grow that wraps, then impl would just pretend there is
            1 row and max-content would be widest item which is not
            the case when it wraps.
  fantasai: that kind of thing where a simple approach was taken ???
  fantasai: people are therefore relying on weird behavior

  iank: I think we can fix flex-wrap column case
  fantasai: The hardest one!
  iank: Like col wrapping flexbox boxes are minimal while the number
        of row flexboxes is high
  fantasai: I have not dug into this issue, but wonder if we at some
            point might need a switch sizes property
  iank: I think we can get a long way there. ???. It would be nice,
        but I am not hearing from devs about the brokenness, as
        opposed to the column wrap case
  iank: The row case is “sure, whatever”. Don't know how much value
        there is in a switch for devs.
  iank: We would have had a lot more reports about it

  astearns: So, what do we want to do?
  fantasai: I think Tab and I are gonna need to do a follow up and
            figure out what spec changes are needed and also what
            comes back from web compat
  iank: Having a quick look at definitive flex basis case is pretty
        simple. We are 90% sure that we can do this change.
  iank: It seems like a col wrap case and not a lot people set a flex
  iank: If we get a resolution about path forward with flex basis
        algorithm then we can roll forward. Won't push to beta channel
        without out
  fantasai: Seems like step in right direction. We should take
            resolution to support going in this direction
  TabAtkins: Yeah
  iank: Yeah, we think this is a flaw and that we can ship this
  iank: incremental changes
  iank: I think that is path forward
  fantasai: From spec perspective we ???
  astearns: Take the algorithm that is in the spec that turned out to
            be problematic from a compat concern, leave it in the spec
            as informative note with explanation about it being a note
            and then add this 1 change so that blink can try shipping
  fantasai: It is creating an algorithm for … we have to draft the
            algorithm + blink change
  fantasai: it is adding a new algorithm
  fantasai: I agree on keeping it as informative note
  fantasai: with mention that we are going to tweak it more
  iank: At the very least, also writing down what browsers are
        currently doing
  iank: and the incremental thing

  astearns: So first resolution is to take existing algorithm, mark it
            as informative, and explain why that is.
  astearns: Objections?

  RESOLVED: Take existing algorithm, mark it as informative, and
            explain why that is.

  fantasai: Second bit is to tentatively spec what chrome has
            implemented, and mark it as tentative
  iank: Also tweak it if there is feedback
  astearns: Objections?
  astearns: With intent to improved it as much as we can
  astearns: Proposed is to tentatively spec what is interoperable for
            this area of flexbox sizing, and mark it as tentative
  fantasai: I'd rather spec what chrome is doing
  astearns: Other browsers any concerns about this?
  dholbert: Seems fine to me
  sammy_gill: Double check that is the conservative and web compatible
  iank: Yes, web compatible up to canary
  iank: We might find out that we broke stuff when pushing to beta
  astearns: And you said you found 6 issues?
  iank: Yes, we've had cases that broke large sites

  RESOLVED: Spec what chrome has implemented in canary currently

  TabAtkins: It is in the thread
  astearns: (missed)

CSS Grid Continued

Honoring the specified width/height of a subgrid
  github: https://github.com/w3c/csswg-drafts/issues/8966

  alisonmaher: There are three different parts to this issue
  alisonmaher: First example, we are in subgrid in both directions with
               width of 50px. According to spec subgrid is always
               stretched in subgridded dimensions
  alisonmaher: We like to confirm width should be ignored, given that
               cols are subgridded. blink stretches but webkit sets
               size of subgrid to 50px and gecko is doing combination
               where text is stretched but subgrid is 50px
  alisonmaher: width should be ignored here
  fantasai: Yes, that was intention of the spec

  alisonmaher: Any more comments?
  astearns: Action here is to file bugs for other vendors

  alisonmaher: In 2nd example subgrid is not ?? and we like to
               confirm ???
  fantasai: You only ignore alignment and sizing in the subgridded
            axis, not in the other axis
  alisonmaher: That makes sense
  astearns: Action is to file a bug for blink

  alisonmaher: 3rd example the subgrid inline axis is not subgridded.
               Question is should we ignore min content size of the
               subgrid and instead use the specified width 50px. This
               would ??? to overflow available space
  alisonmaher: gecko and webkit use specified width, while blink
               considers the min content size
  fantasai: So this is a subgrid, subgridded in the block axis but not
  fantasai: you should honor the width
  alisonmaher: Then we should file a bug as well

  astearns: And please add WPT for all scenarios
  iank: There is mininal test cases but generally the whole subgrid
        area is under tested
  iank: This set of fixes on the blink side are relative major, so we
        want to make sure beforehand that this is the expected thing
  astearns: Proposed resolution to close no change. Spec is what we
            intended. Action to file bugs on browsers and create WPTs
  astearns: Objections?

  RESOLVED: Close no change. Spec is what we intended. Action to file
            bugs on browsers and create WPTs


Use cases for margin-trim on floats
  github: https://github.com/w3c/csswg-drafts/issues/8547

  Sammy_Gill: This is an open ended discussion. While doing some
              prelim work on floats we found that there are some
  Sammy_Gill: We want to come back to the working group and see if
              there has been high demand or if there are significant
              benefits to authors
  fantasai: (draws on whiteboard: float with some text wrapped
            around it)
  fantasai: I can see wanting to trim both in-flow and float margins.
  fantasai: I have a page with some text at the top and an image here
  fantasai: you generally want float and text to be flush at the top
  fantasai: if we trim all margins on the inline stuff but not the
            float, you are gonna have a margin at the top only on the
            float, so they won't be even
  fantasai: Why the margin? maybe you have two floats, not sure which
            one(s) end up flush with the top.
  fantasai: I can see having separate controls for floats vs in-flow
  fantasai: It is possible that if you float something, it is not
            furthest to the side
  fantasai: so you might not be able to select the float that is flush
            with the side
  fantasai: that is the use case

  iank: I think when yeah it is sort of a judgement call. some folks
        want it, some don't
  iank: The implementation complexity is significant
  iank: For example, if you trim, then that float might get placed
        somewhere else
  iank: Another one is that you may have to restyle layout from the
        root like bfc to get the layout to be correct.
  iank: You might need to backtrack the whole entire way
  iank: Very complex

  florian: For floats that are meant to be floats, looking at print is
           a good source of use cases
  florian: If you look at antenna house formatter (css to pdf tool)
           they do this slightly differently. Instead of margin
           trimming they let you set multiple types of margin, e.g.
           float-to-float margin, float-to-text margin,
           float-to-container margin, which you can set separately,
           but that might not remove complexities
  florian: where you try to do a book-ish layout, you might need it
  iank: A simple formatter might get away with this, but here its more
  astearns: That said, existence of these controls in print formatters
            is evidence that some people do want to have control over
            these things
  iank: Yeah. From what I have seen, some people do want to
        control this
  iank: but compared to the general feature it is less
  iank: The demand is not as large from what I have seen

  fantasai: One question: are complexities from both axis or just from
  iank: The block start margin is likely fine modulo the placement
  fantasai: That might be acceptable
  fantasai: Inline dimension there is complexities like block end
  fantasai: Complexities on all sides. least troublesome is block
            start. most is block end
  <dbaron> (inline dimensions in the middle for how troublesome)
  fantasai: Block end margin is complicated? Doesn't it only apply to
            bfc root?
  Sammy_Gill: The trimming for block end margin extends through entire
              bfc and not just the block
  fantasai: For the block-end margin, the float does not cause the
            non-bfc-root to grow/shrink
  iank: ...except when you have clearance
  fantasai: If we had margin trim on block end side apply only to bfc
            root would probably satisfy the use cases
  iank: It still is complex. that float might before the content. If
        it has end margin ??? it might get replaced ??? so you might
        need to backtrack
  fantasai: But you don't remove bem?
  iank: That still is ???
  fantasai: It probably should not
  fantasai: It should not cause the float to be placed again (?)
  fantasai: The margin trim should not on the bottom not cause it to
            move. It should allow the bottom margin of the bfc to
            shift upwards until it is flush with the bottom-most
            border edge of the floats
  fantasai: I think what won't cause problems

  fantasai: I think use cases for block layout in general is block
            axis margin. Can't think of example for inline axis
            trimming except for floats
  iank: There is still issues with blocks and margins
  astearns: It may be around float stacking where bottom edge of one
            float can affect a subsequent float
  iank: Yeah, also fun stuff about <br> that clear stuff
  iank: brs get complicated
  iank: brs are magical

  florian: So my takeaway that there are usecases and it is hard
  florian: Suggestion to take it back to github
  fantasai: Suggestion not apply margin trim by default to floats, try
            and find a syntax that would allow margin trim to apply to
            only floats or floats and all other content, and then work
            through some of the block axis issues at least
  myles: One side is about implementation discussion, then making this
         an author opt in does not help
  fantasai: But then you can implement it in stages
  iank: If we make default not apply to floats, then webkit can
        implement without affecting floats then we can add an
        extension to floats which we can decide upon later
  florian: opt-in to be defined later also allows for introducing
           partial solutions as opt ins, if we can find some that are
           reasonably easy to implement and do solve meaningful
           subsets of use cases

scribe: dbaron

  myles: Main concern is about implementation cost of final thing
         eventually in the future.
  myles: staging it out over years doesn't satisfy that.
  myles: If we end up with multiple different opt-ins, problem is
         worse in the end.
  fantasai: It seems that an author might reasonably set it
            independently for inline flow and floats.
  fantasai: otherwise I wouldn't want this
  myles: I'm not making a judgment about one side of the issue or the
         other, just trying to clarify about implementation complexity.
  fantasai: I want to talk more with Ian to understand where the
            complexity is coming from.
  fantasai: I wonder if the complexity is actually intended.
  fantasai: Some of the complexity may not be desirable
  iank: Sammy_Gill may have more of it loaded in his head right now.
  iank: Discussion I had with Alan at WebKit a while ago.
  astearns: Not as much about margin-trim itself, but how it affects
            all of float positioning which is complicated
  Sammy_Gill: Example here is reasonable, but when you make it apply
              to all floats then it gets hairy
  iank: If we resolve not to apply to floats in the moment... web
        developers are great at telling us when they think something
        is broken, so we can get a sense of demand later on
  myles: Sounds like a great compromise

  florian: In terms of usage, ... usable-ness of floats increases
           significantly with well functioning fragmentation and page
           layouts. So we don't see this much on the web. If we
           increase our fragmentation capability, we might also
           increase our need for fancy floats, which will remain
  florian: Original use case for floats not used all that often on the
           web, but used plenty on paged media
  myles: Comment about usage of floats or about margin-trim?
  florian: Floats in general... but once floats are used more, people
           will want more fancy floats features
  hober: Aren't floats used all the time, to a first approximation?
  fantasai: Way they're used on the web and the way they're used in
            paged media are quite different
  fantasai: Many ways they're used on the web are correctly being
            replaced by grid and flexbox
  fantasai: If we had developers trying to do what floats were
            intended for on the web, demand for these features would
  myles: I think we should tentatively resolve that they don't apply
         to floats, and then try to understand use cases and slice/
         dice issues.
  astearns: proposed resolution: margin-trim doesn't apply to floats
            (by default), and we'll explore the interaction in the

  RESOLVED: margin-trim doesn't apply to floats (by default), and
            we'll explore the interaction in the future

Received on Sunday, 10 September 2023 15:11:20 UTC