- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 10 Sep 2023 11:10:09 -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 Grid
--------
- RESOLVED: Accept edits [in this commit
https://github.com/w3c/csswg-drafts/commit/0cadf5297d3fd3584ca8a74ac0a86d6f28ab4ca2
]
(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:
https://github.com/w3c/csswg-drafts/issues/3565#issuecomment-1638901643
]
(Issue #3565: minmax(auto,min-content) under a
max-content constraint)
===== FULL MEETING MINUTES ======
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,
100px);
<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:
https://github.com/w3c/csswg-drafts/commit/0cadf5297d3fd3584ca8a74ac0a86d6f28ab4ca2
<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
space
fantasai: [explains the problem in a whiteboard]
astearns: For this example how are we choosing to fit the right col
first?
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
this)
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:
https://github.com/w3c/csswg-drafts/issues/2356
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
notes...
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,
max-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
max-content
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
similarly?
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
earlier
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
<br>
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
sensible
<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
but..
<fantasai> modified testcase, removed the width:0 on body -
https://jsfiddle.net/4edu3v7z/1/
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
content
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
https://github.com/w3c/csswg-drafts/issues/3565#issuecomment-1638901643
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:
https://github.com/w3c/csswg-drafts/commit/35ed93fc9296e6541e83c8cca4b705b7ba82c31a
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
on
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