W3C home > Mailing lists > Public > www-style@w3.org > October 2022

[CSSWG] Minutes TPAC/Vancouver 2022-09-15 Part V: Flexbox [css-flexbox]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 25 Oct 2022 18:38:31 -0400
Message-ID: <CADhPm3sZQ0wrEQJLPWiAWEBVGCjikLRO_dVRA5o8hOFLChRB5g@mail.gmail.com>
To: www-style@w3.org
=========================================
  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 Flexbox
-----------

  - RESOLVED: Use the transferred size suggestion in preference to the
              content size suggestion, where that exists, for replaced
              elements (Issue #6794: Change content-size suggestion to
              min-intrinsic instead of min-content?)
  - There still isn't consensus on #6794. Discussion will continue
       between interested groups and on github.
  - RESOLVED: Accept changes, close the issue (Issue #7189: Intrinsic
              Main Size algo has errors)
  - RESOLVED: Accept the proposal in the issue [proposal:
              https://github.com/w3c/csswg-drafts/issues/6777#issuecomment-1220003107
]
              (Issue #6777: column wrap intrinsic size algorithm can
              make inline min-content > max-content)
  - RESOLVED: In the UA style sheet, we keep `svg { overflow:
              hidden; }` (Issue #7714: overflow clip on SVG elements
              and flex layout)
  - RESOLVED: In the flex spec, for auto min sizing, instead of saying
              scroll container, we read the computed overflow property
              value (Issue #7714)
  - RESOLVED: overflow:hidden on replaced elements gets coerced to
              overflow:clip at paint time (Issue #7714)

====== FULL MINUTES BELOW ======

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

Scribe: heycam

CSS Flexbox
===========

Change content-size suggestion to min-intrinsic instead of min-content?
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6794

  dgrogan: This is about how the automatic minimum sizing for flex
           items works with items that have an aspect-ratio
  dgrogan: non-replaced items with an aspect-ratio
  dgrogan: Elika summarized it nicely
  dgrogan: Ultimately it's a conflict between when an aspect-ratio
           item would overflow the container: do we want to destroy
           the aspect-ratio and let flex's shrinking properties
           override it to avoid overflow?
  dgrogan: or preserve the aspect-ratio, with potentially some overflow?

  <dgrogan> https://jsfiddle.net/dgrogan/zcL7qs2v/5
  dgrogan: I would argue that we want to preserve the aspect-ratio, in
           part because authors seem to want their aspect-ratios
           preserved
  dgrogan: I just looked on Stack Overflow, I looked at the first 10-15
           aspect ratio questions, mostly they're about flex destroying
           their aspect-ratio
  dgrogan: if they want it destroyed because they don't want overflow,
           they can specify min-width:0
  dgrogan: this issue is only about what we want in the default case

  fantasai: The initial value of min-width is auto, was introduced to
            prevent overflow when the author wasn't expecting the screen
            to be as narrow as it is
  fantasai: The case here is the flex item is shrinkable, and is in a
            container that's smaller than its aspect-ratio derived
            size, but larger than its min-content width
  fantasai: do we want it to shrink right down to the min-intrinsic
            size?
  fantasai: It prevents one kind of overflow but causes another
  fantasai: If authors don't want a box to shrink below its specified
            size, whether it's specified through width or aspect-ratio,
            they shouldn't be having the box be a shrinkable flex item

  fantasai: the purpose of min-width is a safety mechanism. preferred
            size is expressed through the width property
  dgrogan: I don't follow the argument about min-width not being the way
           to set a preferred size
  fantasai: If your preferred size is something with an aspect-ratio,
            and you set it width width/height, then min-width is a
            stopgap to prevent bad cases of overflow
  fantasai: not to make your design look perfect, which is what width
            expresses
  dgrogan: I see what you're saying. I can take the other way
           symmetrically, specifying the preferred main size through
           the aspect-ratio and the height
  dgrogan: When we let the author set an aspect-ratio and a cross size,
           we're kind of promising that we'll respect that, they went
           out of their way to set that
  fantasai: Same when the author says width:100px, but we break that
            when the item is shrinkable, since you've asked it to be
            shrinkable
  fantasai: don't think aspect-ratio is less of a constraint than width

  dgrogan: Authors seem to really hate when their aspect-ratios are
           broken
  dgrogan: I don't think it's obvious that aspect-ratio is the same
           strength as width
  dgrogan: it's not clear they're setting something as flimsy as a
           width, when they set aspect-ratio

  IanK: I think more opinions might be good from the author side of
        things
  dholbert: I'd question analogous situations. are there other cases
            where you set an aspect-ratio, and you stretch in both
            directions, like a grid cell?
  fantasai: When you set width/height on an element we ignore
            aspect-ratio completely
  IanK: The trick with flexbox is that it has a strong explicit stretch
        in the cross axis, by default

  miriam: I can see use cases where I want it to shrink, and others
          where not
  miriam: how easy is it for the author to specify that?
  miriam: Wondering if adding flex:0 is clear
  fantasai: That would cause it not to shrink. initial value allows
            shrinking but not growing
  miriam: I'm wondering if we were going with the other default, what
          would be the counter author solution to say, allow shrinking?
  IanK: flex:0 will still allow shrinking
  dholbert: flex:none is what you want
  fantasai: They're the same
  IanK: No
  fantasai: Initial value is "1 0"
  dgrogan: I think we all agree on flex:none
  <TabAtkins> Right, `flex: 0` is equivalent to `flex: 0 1 0px`

  dgrogan: if we go with the opposite default, you'd have to go out of
           your way to say min-width:0
  dholbert: min-width:0 would cause more overflow than the opposite
  dholbert: it doesn't precisely undo it. that would allow things to
            compress to 0.
  dholbert: min-content or min-intrinsic
  IanK: min-content would do the right thing
  fantasai: It's not quite exactly that
  fantasai: min-content will win
  fantasai: auto minimum size, because it's trying to be a
            non-intrusive safety mechanism, if you have some explicit
            size on it, it'll take the minimum of that and the
            min-content size
  fantasai: so you can't get the auto behavior by setting min-content
  miriam: I don't have an immediate sense of which one I want more often
  miriam: flex:none seems the simpler fix though
  fantasai: min-width:auto also resolves to 0 if you're a scroll
            container
  fantasai: there's a lot of magic in min-width:auto, to make it weaker
            than other author expressed constraints
  fantasai: It's always trying to find what's the smallest size to
            prevent overflow and also not interfere with other
            constraints

  dgrogan: Glad you brought up min-width:auto magic
  dgrogan: One proposal in the bug, from Ian in March, is redefining
           min-content for non-replaced aspect-ratio items to
           incorporate the auto min width from the aspect-ratio in
           css-sizing-4
  dgrogan: if we did that, we'd end up with the aspect-ratio preserving
           behavior in this case
  dgrogan: but it would do so in a way that would 1. a lot of magic
           would go away, min-width:auto becomes simpler to spec, and
           2. it becomes easier to implement, and the auto min width
           for aspect-ratio items totally ignoring flexboxes also gets
           easier to implement
  dgrogan: In the 2 years this has been specced, it's been really hard
           to implement
  dgrogan: Ian has a big test case that shows some of this
  dgrogan: I think based on my knowledge of Blink/WebKit/Gecko, if we
           did Ian's proposal, implementation becomes simpler, and we'd
           be way more likely to get interop
  dgrogan: If we stuck with the magic in auto min-width, we're not
           going to get interop on a lot of this for a long time
  dgrogan: if ever
  dgrogan: We've all had a really hard time implementing this, and got
           lots of bug reports

  Rossen: Becoming a bit more pragmatic, rather than chasing spec purity
  Rossen: can we do that moving forward? if we can, do we have enough
          buy in from implementers?
  dholbert: what's Ian's proposal?
  IanK: Effectively, instead of having a separate min intrinsic and min
        content size, you incorporate the min-width:auto behavior in
        min-content
  IanK: Currently, we're the only implementation that explicitly
        created a separate min intrinsic size
  IanK: and effectively, that would disappear, and when you're
        calculating min-content for the box, you also apply the
        min-width:auto logic on top of the aspect-ratio logic
  fantasai: Not following. We explicitly wanted to say min-width:auto
            would break aspect-ratio
  fantasai: having min-height break but not min-width ...
  IanK: min-width:auto would still encompass this, it just wouldn't
        shrink
  dgrogan: I think Safari does this today
  IanK: Safari's min-content implementation basically does this already
  IanK: in some of the complicated test cases, Safari kind of does what
        I'm suggesting
  dgrogan: But we all have many bugs in this area
  IanK: Engines also struggle with width:100% and width stretch being
        different

  Rossen: What's the proposal here?
  <fantasai> https://jsfiddle.net/dgrogan/zcL7qs2v/5
  <fantasai> https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-1218597495
  fantasai: We walked through a bunch of cases ^
  <fantasai> https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-1220038900
  <fantasai> latest proposal from me and TabAtkins ^

  IanK: I also wanted to note, we can't change replaced elements. they
        have to stay at min-content
  IanK: There's too much of the web that relies on them preserving
        aspect-ratio
  IanK: We accidentally broke this recently and got bug reports quickly
  IanK: Can't shrink replaced elements below their min-content size
  dgrogan: I think your point Ian is that if we can't change replaced
           elements, they currently do what non-replaced elements
           currently do
  IanK: Replaced elements will always pass through their aspect-ratio,
        and we can't change that
  IanK: the min-width for these aspect-ratio items would be largest of
        their min intrinsic width, or their aspect-ratio derived width

  fantasai: Tab and I don't really like the idea of incorporating
            min-width:auto into min-content definition
  fantasai: because it really should be the other way around
  fantasai: If you set width:min-content, you're proposing that the
            resolution of that min-content value to a concrete value,
            looks at the min-width value, and if it is auto,
            incorporates some extra magic
  fantasai: if it's not auto, does not have magic
  fantasai: but if you set min-width:min-content, it cannot depend on
            the min-width property itself
  fantasai: so the min-content keyword means two different things,
            depending on where you set it
  fantasai: We think this should be more consistent, and independent of
            what sizing property you set it on
  fantasai: whether it's on width or min-width, its used value is the
            same
  IanK: We already look at the width properties in the min-content
        algorithm. there's already a bunch of compressibility stuff,
        special table stuff
  IanK: this is fine from an engineering point of view

  dholbert: I'm a bit confused about that stating of the proposal
  dholbert: it sounds like we're talking about what should happen when
            you have an element with an aspect-ratio that's forced to
            shrink
  dholbert: sounds like that's talking about what the magic is behind
            min-width:auto. not about how it gets incorporated
  fantasai: The compressibility stuff affects the min-content
            contribution, which is not the same as the min-content size

  dgrogan: I think Ian's saying it's fine from an implementation PoV
  dgrogan: I think of this as how the min-width:auto magic is
           incorporated
  dholbert: min-width:auto resolves to come length
  dholbert: sounds like the proposal is to resolve it to a different
            length
  dholbert: that takes into account the aspect-ratio more eagerly
  dgrogan: I'm not talking about the min-content algorithm more eagerly
           taking it into account
  dgrogan: Right now, it ignores min intrinsic size and only looks at
           aspect-ratio
  dgrogan: so if anything this proposal is to do it less eagerly
  IanK: We also look at aspect-ratio for the min intrinsic size,
        because we transfer through the max height and min height
  IanK: and that affects the min intrinsic size
  IanK: min-intrinsic and min-content are almost always the same

  Rossen: Still not seeing something we can resolve on
  Rossen: sentiment here is clear, but I still don't see what to
          resolve to move forward, that satisfies implementability and
          the developer pain


  Rossen: Elika's pointing out another part of the issue, that
          articulates what we should and can do for replaced elements,
          and for non-replaced elements the explanation here still
          doesn't give enough specify that suggests a change
  <fantasai> https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-1220038900
  fantasai: We are suggesting several specific changes
  fantasai: Tab and I are saying it shouldn't be considering
            aspect-ratio
  fantasai: when we originally wrote the text for min-width:auto, there
            wasn't aspect-ratio on anything except replaced elements
  fantasai: in that context, it doesn't make sense to incorporate
            aspect-ratio
  fantasai: so we really meant min-intrinsic size despite not having
            that term yet
  fantasai: [the other two points are there in the link above]

  fantasai: In flex/grid when you have a transferred size, it's
            different in grid the transferred size takes precedence
  fantasai: but in flex it takes the min of the two
  fantasai: It seems that would probably not be a good idea for compat,
            given where implementations are right now
  IanK: That's something we can resolve on. For replaced elements, for
        compat, we need to keep it as min-content
  fantasai: I'd phrase that as "use the transferred size suggestion in
            preference to the content size suggestion, where that
            exists, for a replaced element
  IanK: For us they're basically equivalent
  IanK: When do they differ?
  fantasai: Because the content size suggestions do not take
            aspect-ratio into account
  fantasai: if it did, then there wouldn't have been a transferred size
            suggestion in the first place
  IanK: This is flex box's content size suggestion, not min-content
        size we use elsewhere

  RESOLVED: Use the transferred size suggestion in preference to the
            content size suggestion, where that exists, for replaced
            elements

  fantasai: There was a comment in the thread about how transferring
            the max size from the opposite axis didn't make much sense
  dgrogan: In the content size suggestion?
  fantasai: For non-replaced
  fantasai: right now we transfer a max size constraint from the
            opposite axis to clamp the min in this axis
  fantasai: that probably doesn't make sense

  dgrogan: We still have a fundamental disagreement about the main point
  dgrogan: I just want to fall back, all 3 engines tried and we're in
           the place where we don't have much interop
  dgrogan: The suggestion of incorporating the auto min width into the
           min-content calculation, it's not great, but it's practical,
           pretty sure all engines can do it easily, and we'd get
           interop way easier
  chrishtr: You also said impl difficulty and web compat prevented you
            from implementing the alternative?
  Rossen: No that's for replaced elements
  dgrogan: It's related
  dgrogan: We're talking about changing the rules. and one of them
           would've changed replaced, but we can't do that
  chrishtr: So we special case replaced elements, for compat
  dholbert: To be fair, non-replaced elements do have a meaningful
            smaller min width

  IanK: I'd still like to hear from more web devs about what they
        expect of the default
  IanK: and how they'd work around that
  IanK: heard from Miriam
  dgrogan: It's not just implementation. If we resolve on Ian's March
           proposal, it becomes easier to implement, and we think it
           doesn't break user expectations
  IanK: Adam Argyle weighed in on that

  miriam: I have use cases that I'd want to go either way, so more
          important to me is that I have the tools to get non-default
          behavior when I need it
  miriam: flex:none, to say "preserve my aspect-ratio" worked for me
  miriam: if there's a similar switch from the other side, then it'd
          work for me too
  fantasai: But there isn't one from the other side
  fantasai: flex:none is the thing to use to prevent it from going
            below its minimum size
  chrishtr: Do we need something for the other case?
  fantasai: That's what min-width:auto is for
  chrishtr: Is there some other way to get this use case that Miriam
            says is legit?
  dgrogan: I don't really understand why some fixed value of min-width
           wouldn't work well
  dgrogan: even if it doesn't cover all cases, I think it'd be close
           enough
  dgrogan: Don't understand why min-width is not enough
  miriam: It might be for my cases, would have to look more

  fantasai: Would point out that explicit min-width is a strong
            constraint
  fantasai: if you put min-width:min-content, that's winning over all
            other size constraints
  fantasai: min-width:auto is a weak constraint
  fantasai: everything else will win over it
  fantasai: so if you want to set some kind of minimum, you want it to
            be a weaker one than other constraints? like max-width? you
            can't do that with min-width, because that will win over
            everything else
  dgrogan: You can do min-width:10px
  fantasai: Is an arbitrary length value what you want?
  fantasai: or something based on the content?

  dgrogan: I don't know where we go from here
  miriam: Would also say that the fact it's not flexing to grow ...
          would it maintain the aspect-ratio?
  miriam: I'd expected it to do the same thing growing as shrinking
  IanK: If flex-grow:1, it will trash the aspect-ratio
  miriam: I'd expect them to work the same way

  IanK: The problem we get into is that flex-shrink being 1 everywhere
        is ...
  fantasai: Being the default is what's throwing people for a loop
  fantasai: if they also set width:100px on it and notice that shrinks
            but doesn't grow, that's consistent
  fantasai: whatever width you have preferred, it will shrink but not
            grow, by default, in flex
  Rossen: still not hearing a concrete path forward here
  Rossen: I think this would benefit from some whiteboarding

Intrinsic Main Size algo has errors
-----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7189

  TabAtkins: This one should be easier
  TabAktins: We noticed an error, discovered what it was, talked it
             over with David, fixed it to his satisfaction
  TabAktins: we asked for a review few weeks ago, if no comments, we
             can go ahead and accept it
  <fantasai> https://github.com/w3c/csswg-drafts/commit/d452a10a921391dc6b6a96e7be97218692c1de53
  fantasai: This is already folded into the spec
  dholbert: I haven't had a chance to look
  dholbert: I could take a quick look offline. but I suspect it's fine.
  IanK: We are still implementing this. don't know what the compat
        fallout will be
  IanK: but we need to try to work out what that looks like
  IanK: this is just a bit hairy because we've all had the same
        intrinsic sizing algorithm for a while

  RESOLVED: Accept changes, close the issue

column wrap intrinsic size algorithm can make inline min-content >
    max-content
------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6777

  <fantasai> proposal:
https://github.com/w3c/csswg-drafts/issues/6777#issuecomment-1220003107
  dgrogan: This one is similar to the last one
  dgrogan: There have been spec proposal, but fantasai made a good
           proposal, implemented it not shipped, but it works well
  dgrogan: From calculating the min-content width of a column wrapped
           flexbox, instead of laying out all the items at their
           min-content width and then taking the result and calling
           that the min-content width
  dgrogan: we'll just ignore wrapping
  dgrogan: so the min-content width of a column wrapped flexbox will be
           the same as a non-wrapped flexbox
  dgrogan: Downside will be is there can be some overflow if the column
           wrapped flexbox has a definite height specified, such that
           the items need to wrap, but now they can't
  dgrogan: Also point out this proposal is what all browsers implement
           today
  dgrogan: so it seems fine
  dholbert: Seems fine to me
  fantasai: That's for min-content sizes
  fantasai: guarantees even if you have overflow columns, the width of
            the box will be as wide as the widest column

  fantasai: trickier is max-content size, where there's no real good
            answer
  fantasai: Proposal is to lay out each item at its max-content size,
            then try to build the columns, then try to wrap a box
            around that set of columns
  fantasai: Mostly that should be a box that can size its contents
            exactly, but if the author used %age sizing there'd be
            cyclic effects
  dgrogan: What fantasai just proposed is already specced

  RESOLVED: Accept the proposal in the issue

overflow clip on SVG elements and flex layout
---------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7714

  khush: This concerns how the min width / min-height auto is computed
         for a flex child
  khush: Spec says that if an element is a scroll container, the
         min-width/height will be 0
  khush: but if not a scroll container, then it's content based min size
  khush: The two cases where it's not a scroll container, is if
         overflow is clip/hidden
  khush: previous change made replaced elements [...]
  khush: SVG has for a long time had `overflow: hidden` in the UA style
         sheet
  khush: now we're setting overflow:clip, it causes this layout behavior
  khush: Before, min-width/height would be 0
  khush: but now it's computing to the content based min size
  IanK: We got many bugs
  khush: Fun part is that was accidentally rolled out to stable channel
  khush: have to keep this behavior for compat

  khush: Options are to first add min-width/height:0 to the UA style
         sheet, which when combined with overflow:clip gives you the
         previous behavior
  khush: but now we have different compat problems
  khush: Second option is to special case it
  khush: either in the layout computation spot. clip behaves this way
         except for SVG
  khush: Other option is that we don't set the overflow:clip in the UA
         style sheet only for SVG, and at layout time the previous
         behavior continues to apply, but at paint time we use it as if
         it's clip
  khush: it'd have to be a used value time thing
  khush: used value would be different in paint time

  fantasai: Maybe should've gone over #7144 first
  <Github> https://github.com/w3c/csswg-drafts/issues/7144 :
          [css-images-4][css-overflow-3] How do `object-overflow` and
          `object-view-box` interact with `overflow` and
          `overflow-clip-margin`?

  dholbert: I'm fond of the third option, keeping overflow:hidden SVG.
            Is there a reason we need to change SVG?
  <fantasai> +1 to keeping overflow:hidden on svg
  IanK: Mainly for consistency
  IanK: we didn't perceive the compat risk
  IanK: only weird quirk is that at layout time, when we're looking at
        overflow, pretend overflow means clip at paint time
  IanK: at layout time
  dholbert: Where is that used value magic? already exists?
  dholbert: seems orthogonal to this
  fantasai: Maybe we should switch to 7144

  emilio: I have a question. overflow:clip by default on SVG, it
          changes the sizing behavior
  IanK: So min-content sizes
  IanK: auto min size will be 0
  emilio: If I load the test case in the first comment, and set
          overflow:clip/hidden, I don't see any layout change
  khush: Flex layout was implemented first, so where it's supposed to
         check is this a scroll container or not, it looks at overflow
         value
  khush: assumes it's not a scroll container only if overflow:visible,
         but we are also now checking for clip
  khush: this is a change in the process of landing
  emilio: Right now SVG is not a scroll container
  IanK: But it does have overflow:hidden
  emilio: Right now that decision is based on scrollable overflow
  IanK: Computed overflow property value
  emilio: And you are changing that?
  emilio: but you want SVG to keep behaving the same way?

  IanK: The flexbox auto min size thing likely needs to say look at the
        computed value of overflow, rather than "scroll container"
  IankK: could make that narrower
  IankK: it becomes a used value, after layout thing
  emilio: I'm still confused
  emilio: I see a difference if I set overflow:visible on the SVG, but
          not if I set overflow:clip
  IanK: We currently don't support overflow:clip
  dholbert: In Firefox I see a difference
  <dholbert> (If I add `overflow:clip` to
https://github.com/w3c/csswg-drafts/issues/7714#issue-1366802020 ,
              then the green thing gets wider)

  IanK: But that's not the compat concern
  IanK: overflow visible/clip should behave the same
  IanK: but we changed the UA style sheet from hidden to clip, and that
        broke things
  emilio: Maybe not change the UA style sheet?
  emilio: since it doesn't create a scroll container either
  IanK: At layout time you use the computed value of overflow, like we
        do right now
  IanK: to determine if we apply the auto min size
  IanK: and at paint time, we convert this to a used value of
        overflow:cip
  emilio: But that's basically what happens now?
  IanK: Differences are overflow clip margin will start to apply

  khush: In terms of the changes in the UA sheet, we can skip setting
         overflow:clip, but we still need the overflow clip margin box
         for it to work with these elements
  khush: overflow-clip: margin-box
  khush: so we'll skip setting overflow:clip, leave it as hidden

  emilio: Proposed solution only changes the UA sheet?
  emilio: Do we need to add magic to make overflow:hidden to behave
          like overflow:clip for SVG, rather than letting authors do it?
  IanK: We had a resolution that overflow:hidden would behave as
        overflow:clip
  IanK: it basically behaves like that anyway
  IanK: this is harmonizing
  emilio: Bit unfortunate
  IanK: The coercion would apply to all the replaced elements, not
        just SVG
  IanK: if they're overflow:hidden
  emilio: As long as you're a replaced element
  emilio: you don't get weird cases where there's only clip on one axis
  emilio: as long as this is well tested
  khush: I promise!

  dholbert: The thing where you check the computed value for flex
            layout purposes, I think that already matches what we
            already do internally, and it's what the spec used to say
  dholbert: it results to 0 if overflow is hidden/scroll/auto
  dholbert: but the spec now says scroll container
  dholbert: so we might want to consider reverting that, and explicitly
            defer to computed overflow value
  IanK: I think I'd prefer that

  IanK: In summary, part 1: in the UA style sheet, we keep `svg
        { overflow: hidden; }`. part 2: in the flex spec, for auto min
        sizing, instead of saying scroll container, we read the
        computed overflow property value
  IanK: part 3: which may already be specced, is overflow:hidden on
        replaced elements gets coerced to overflow:clip at paint time
  dholbert: You can't do scrollTop on an <img>
  khush: Part 3 was resolved in #7144
  <fantasai> +1
  khush: One other thing, for SVG, we're still keeping
         overflow-clip-margin in the UA sheet

  RESOLVED: In the UA style sheet, we keep `svg { overflow: hidden; }`
  RESOLVED: In the flex spec, for auto min sizing, instead of saying
            scroll container, we read the computed overflow property
            value
  RESOLVED: overflow:hidden on replaced elements gets coerced to
            overflow:clip at paint time

<br dur="13m">
Received on Tuesday, 25 October 2022 22:39:13 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:21 UTC