- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 25 Oct 2022 18:38:31 -0400
- 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