- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 19 Aug 2025 08:43:28 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3][Masonry] repeat(auto-fill) and minmax()`. <details><summary>The full IRC log of that discussion</summary> <kbabbitt> alisonmaher: currently in grid minmax can take 1 intrinsic size<br> <kbabbitt> ... but it gets ignored I believe<br> <kbabbitt> ... so now that we're considering allowing repeats with intrinsic size<br> <kbabbitt> ... should we allow a different def for minmax as well within the repeat<br> <kbabbitt> ... sounds like we would<br> <kbabbitt> ... from the discusson<br> <kbabbitt> ... because minmax(auto, auto) is the same as auto<br> <kbabbitt> ... so if we allow a repeat of auto we should also allow some other defs for minmax than are allowed today<br> <kbabbitt> ... problem is that it wouldn't be back compatible for grid<br> <kbabbitt> ... fantasai1 mentioned we might want some other syntax for this<br> <kbabbitt> fantasai1: when we talk about allowing intrinsic sizes for auto fill repeat<br> <kbabbitt> ... that means all sizing keywords as well as minmax ones<br> <kbabbitt> ... right now in grid if you have a fixed size and an auto size<br> <kbabbitt> ... we do a minmax of 100px and auto or vice-versa<br> <kbabbitt> ... that's curently allowed<br> <kbabbitt> ... we count # of columns based on fixed size ignoring auto size<br> <kbabbitt> ... I don't think we should change that for masonry<br> <kbabbitt> ... a grid track listing and masonry track listing should have identical behavior insofar as possible<br> <TabAtkins> q+<br> <kbabbitt> ... but what's new is that you can do auto in the min position and max position<br> <kbabbitt> ... and we don't have a rule of which one takes precedence when trying to figure out how many columns will fit<br> <kbabbitt> alisonmaher: so proposal would be keep same definition for 1 intrinsic size within minmax, for 2 there'd be some new rule<br> <kbabbitt> fantasai1: the question then is, what do we want that new rule to be<br> <astearns> ack TabAtkins<br> <kbabbitt> TabAtkins: I somewhat disagree, I think, that we should have the 1 fixed 1 intrinsic behaviuor match exactly between masonry and grid<br> <kbabbitt> ... behavior we define for grid is because we cannot calculate a size<br> <kbabbitt> ... but we do calculate intrinsic sizes for masonry<br> <kbabbitt> ... I think it would be unfortunate if you couldn't leverage intrinsic sizing when ???<br> <kbabbitt> s/???/when one of the arguments was fixed/<br> <kbabbitt> ... it would be weird if both intrinsic arguments worked but one argument didn't<br> <kbabbitt> ... because that's how grid had to work<br> <kbabbitt> ... so I think we should calc intrinsic sizes in a mixed minmax function<br> <kbabbitt> fantasai1: we either use min or max not both<br> <kbabbitt> ... when trying to figure out column count<br> <kbabbitt> TabAtkins: sure<br> <kbabbitt> fantasai1: are you proposing we always use min? or max? or ?<br> <kbabbitt> TabAtkins: no change in how minmax is processed<br> <kbabbitt> ... when used in masonry, intrinsic keywords are resolved as masonry defines<br> <kbabbitt> ... rathar than being strictly ignored which is what's in grid<br> <kbabbitt> fantasai1: in order to count number of columns we need a size<br> <kbabbitt> ... that size is not the final resolved size because that depends on extra steps in processing<br> <kbabbitt> ... we're coming up with a size to determine columns<br> <kbabbitt> TabAtkins: spec says when you have minmax if both are fixed we use one size<br> <kbabbitt> fantasai1: the max<br> <kbabbitt> TabAtkins: the spec then says in grid, if one size is intrinsic, we ignore that rule of always use the max<br> <kbabbitt> ... and use whichever one is fixed<br> <kbabbitt> ... in masonry we don't have to ignore intrinsic one, we can calc size<br> <kbabbitt> ... so we should act as normal and do what the spec says for double fixed<br> <kbabbitt> fantasai1: disagree that's what we should do<br> <kbabbitt> ... I think there are use cases for using either min or max<br> <kbabbitt> ... even with fixed sizes or auto auto sizes<br> <kbabbitt> ... and the author should probably be giben the ability to choose explicitly<br> <TabAtkins> minmax(min-content, max-content) is *illegal* in Grid, but meaningful in Masonry. minmax(100px, max-content) should work in the same way (rather than always use 100px)<br> <kbabbitt> ... say I want to count with min, or count with max<br> <kbabbitt> ... we should give author that abiulity by pyutting a keyword in first argument<br> <kbabbitt> ... even for grid there are use cases for wanting this<br> <kbabbitt> ... we should let author choose min or max as counting function<br> <kbabbitt> ... then if the author doesn't specify, they would get an auto default of either min or max<br> <kbabbitt> ... in grid that means use max if both are fixed, if one is fixed use that one<br> <kbabbitt> ... if we co in that direction I think haveing grid and masonry be consistent in which one they use makes sense<br> <kbabbitt> ... because ayuthor will know that's how track listings work<br> <kbabbitt> ... potential for expanding grid tracks to other modes of layout<br> <kbabbitt> ... so having them behave as consistently as possible benefits author<br> <kbabbitt> TabAtkins: I don't disagree with the ability to select you want intrinsic repeats based on min or max<br> <kbabbitt> ... but that's not the issue here<br> <kbabbitt> ... issue here is what to do with double intrinsics or fixed min max in masonry<br> <kbabbitt> fantasai1: I'm arguing that.. .mixed one is something we have already deployed in grid<br> <kbabbitt> ... and we should be consistent with that in masonry<br> <kbabbitt> ... and then double intrinsics is separate question<br> <fantasai1> s/or fixed/or mixed/<br> <kbabbitt> TabAtkins: this was the thing I originally said, and then diverted to different issue<br> <kbabbitt> .... I think it is better for minmax in masonry to be consistent with it self<br> <kbabbitt> ... so heuristics resolve to intriinsic value<br> <kbabbitt> ... than to be consistent with grid, because grid is already inconsistent in double intrinsic case<br> <kbabbitt> ... so since we already have that break which is intrinsic to layout model I don't think it's valuable to stick to consistency argument<br> <kbabbitt> ... where instead self-consistency could give authors more power<br> <kbabbitt> ... example above in chat<br> <TabAtkins> minmax(min-content, max-content) is *illegal* in Grid, but meaningful in Masonry. minmax(100px, max-content) should work in the same way (rather than always use 100px)<br> <kbabbitt> fantasai1: it is no longer going to be illegal in grid<br> <kbabbitt> ... has to be legal in grid to be leagal in masonry<br> <kbabbitt> ... I think we should come up with a definition that's useful in grid and isn't just 1 track<br> <oriol> I think I'm leaning more towards Tab's arguments<br> <kbabbitt> ... should be possible to do<br> <lea> q?<br> <kbabbitt> ... even so if you have that one track, I don't see the idea that we always take the max as being ...<br> <kbabbitt> TabAtkins: that's a separate issue<br> <kbabbitt> ... controlling min max<br> <kbabbitt> fantasai1: so masonry we alwasy use max?<br> <kbabbitt> TabAtkins: no, in masonry intrinsics are valid sizes in minmax<br> <kbabbitt> ... so we should act same as we do in other cases<br> <kbabbitt> fantasai1: which is use the max<br> <kbabbitt> TabAtkins: I don't care whetehr we use max or min, I care about consistency in fixed vs intrinsic sizes<br> <kbabbitt> fantasai1: grid doesn't have that consistency<br> <kbabbitt> ... if you say minmax 100px auto in grid<br> <kbabbitt> ... you get column count based on 100px<br> <kbabbitt> ... if we don't in masonry that's confusing<br> <kbabbitt> alisonmaher: so many differences it's confusing anyway<br> <kbabbitt> fantasai1: if all items are same size which is typical<br> <kbabbitt> ... author has consistent set of items with same size doing a track listing<br> <kbabbitt> ... it would be good if that track listing meant the same thing in grid as it does in masonry<br> <kbabbitt> ... having it different is confusing<br> <kbabbitt> TabAtkins: cases we're talking about are already different<br> <kbabbitt> ... we already have different interpretations between grid and masonry with intrinsic sizes involved<br> <oriol> q+<br> <kbabbitt> ... even if we define intrinsic sizes, it will be different ingrid than masonry<br> <kbabbitt> alisonmaher: even writing tests myself, with repeat 4, I would get different track sizes because we place largest contribution in every spot<br> <kbabbitt> fantasai1: yes but many use cases for auto-fill are consistent set of items consistently sized<br> <lea> q+<br> <kbabbitt> ... having 4 auto tracks in grid will give same size in every track<br> <kbabbitt> ... same thing in masonry<br> <kbabbitt> ... that's main use case for auto-fill<br> <kbabbitt> ... should not be desinging for others<br> <kbabbitt> alisonmaher: I think about cases where ... if theyre consistent sizes then yeah<br> <kbabbitt> ... you can come up with cases where same track definitions give you different results in masonry vs grid<br> <kbabbitt> ... because of how we size tracks<br> <kbabbitt> fantasai1: if you have different sizes then yes, but that's not main use case<br> <astearns> ack oriol<br> <kbabbitt> oriol: I think that overall I'm aligning more with Tab's arguments<br> <kbabbitt> ... fantasai1 was saying when both min and max are valued we take max<br> <kbabbitt> ... but in grid you take max of them, right?<br> <kbabbitt> TabAtkins: the max floored by the min, which is max of two arguments<br> <astearns> ack lea<br> <kbabbitt> lea: I'm getting hte sense this discussion has gone in the weeds but it would be useful if someone could summarize proposals<br> <kbabbitt> .... arugment for same number of columns between the two does seem compelling<br> <kbabbitt> ... fact that some intrinsic size keywords don't work in grid is a continuous pain point for authors<br> <kbabbitt> ... not sure it's something we should emulate<br> <kbabbitt> ... I think it might help if someone could summarize proposed resolution<br> <kbabbitt> fantasai1: you're doing an auto fill repeat<br> <kbabbitt> ... goal is to find out # of columns that will fit in container<br> <kbabbitt> .... question is what size to use to figre that out<br> <kbabbitt> ... when trying to figure out # columns you haven't placed items so you don't know hwat's where<br> <kbabbitt> ... you need a sizing func you can use before placing items<br> <kbabbitt> ... for grid we decided that if you put fixed sizes into repeater, it's easty we take that fixed size andm ultupoly it<br> <kbabbitt> ... and we kow how many column sbased on that<br> <kbabbitt> ... but if you have intrinsic size, ti depends what items are in that column<br> <kbabbitt> ... for grid we disallowed syntacically having size that was purely intrinsic in repeater<br> <kbabbitt> ... if you give a minmax with one fixed and one intrinsic size, we use the fixed size to calculate the column count<br> <kbabbitt> ... for masonry there's an argument that, what if we just say every item exists in every column<br> <kbabbitt> ... then calculate intrinsic size big enough to hold every item as if it were only column<br> <kbabbitt> ... then use that size to calculate column count<br> <kbabbitt> ... then we would be able to have a coloumn count base don intrinsic sizes<br> <kbabbitt> lea: so the argument is we can do something useful with this now so we should, but it would be inconsistent with grid<br> <kbabbitt> ... and fantasai1 is arguing that it should be consistent with grid?<br> <kbabbitt> fantasai1: yes<br> <kbabbitt> ... other issue is for masonry, can we backport the definition we come uyp with into grid<br> <kbabbitt> ... and use same definition to calculate intrinsic sizes pretending every item is in every column<br> <kbabbitt> lea: between the two it seems it might be more important to follow the principle of least surprise and have the value actually work<br> <kbabbitt> ... fact taht it doesn't work in grid is unfortunate<br> <kbabbitt> ... rather than conssitency of same # of columns between the two<br> <kbabbitt> .. I wish it also worked in grid, sounds promising<br> <kbabbitt> fantasai1: I think we can make it work in grid using same def in masonry<br> <kbabbitt> ... in which if we backport it, why inconsistency?<br> <kbabbitt> lea: if we backport to grid do we have some # columns?<br> <kbabbitt> fantasai1: masonry definition actually makes abunch of assumptions that are not necessarily true<br> <kbabbitt> ... assumes every item is potentially placed in every column which is not tur<br> <kbabbitt> ... if you have sized items they influence size of columns<br> <kbabbitt> ... we ignore tyhat when doing repeaters<br> <kbabbitt> alisonmaher: [missed]<br> <kbabbitt> fantasai1: would require extra layout pass<br> <kbabbitt> ... but it is possible to do that in grid<br> <kbabbitt> lea what's the downside?<br> <kbabbitt> fantasai1: extra complication in grid is because... masonry only has track sizing in one axis<br> <kbabbitt> ... so when sizing item with aspect ratio or orthogonal flows, you need height to get width<br> <kbabbitt> ... for masonry you always know thi sis height of contqainer<br> <kbabbitt> ... for grid there's extra complication where heigth of row can depend on width<br> <kbabbitt> ... they can influence each other<br> <kbabbitt> ... if we want to port this definition to grid, if the author is doing complicated track sizes in both axes, they'll be unhappy<br> <kbabbitt> ... but for a typical use case you are less likely to run into a problem<br> <astearns> q+<br> <kbabbitt> ... so there are cases in grid where because of relationship of width of columns an dheight of rowd<br> <kbabbitt> ... I can have tall item which causes [chain of effects]<br> <kbabbitt> ... during counting of columns we'd have to say, that cyclic stuff isn't taking into account<br> <kbabbitt> ... we have to ahve a basic definition and if you do weird stuff it gets weird<br> <kbabbitt> ... masonry doesn't run into this problem<br> <kbabbitt> ... but we could take same definition from masonry for auto repeat auto and put it in grid<br> <kbabbitt> ... I think we should if we're going to do it in masonry<br> <kbabbitt> lea: web compatible?<br> <kbabbitt> fantasai1: yes because currently disallowed<br> <kbabbitt> lea: web compatible because it's syntactically invalid?<br> <kbabbitt> fantasai1: yes so we can just add it<br> <kbabbitt> lea: don't think it's out of the question authors are trying to do this and leaving it in<br> <kbabbitt> fantasai1: don't think its likely<br> <kbabbitt> astearns: whether we can successfully backport to grid doesn't factor into masonry descision<br> <kbabbitt> fantasai1: if we allow it for masonry that makes it syntactically valid for grid<br> <kbabbitt> ... will change behavior for syntax whetehr we allow it for grid<br> <kbabbitt> ... because they use same property<br> <kbabbitt> lea: so we're locked into what we decide<br> <kbabbitt> ... here<br> <kbabbitt> fantasai1: eitehr we need to make this work in grid, or we say auto repeat auto degenerates into one column<br> <kbabbitt> TabAtkins: if you have a mix, one fixerd one intrinsic size, that is syntactically valid in grid today<br> <kbabbitt> ... has a particular meaning which I argued should be different in masonry<br> <kbabbitt> ... can't change in grid<br> <kbabbitt> ... either we end up with masonry stuck with unfortunate weaker definition<br> <kbabbitt> ... because that makes it consistent with grid<br> <kbabbitt> ... or we have a divergence in behavior<br> <kbabbitt> ... in the double intrinsic case too which makes it not very surprising<br> <kbabbitt> fantasai1: our position is that we should have consistency between grid and masonry as much as possible<br> <kbabbitt> ... and if we want other behaviors we should enable for both, possibly with extra syntax<br> <kbabbitt> lea: I think both are reasonabel<br> <kbabbitt> astearns: not following everything but it sounds like if we have consistency between grid and masonry then with the current syntax it's less than ideal for masonry<br> <kbabbitt> fantasai1: for both<br> <kbabbitt> TabAtkins: we cannot change grid's behavior for this case<br> <kbabbitt> ... astearns is right it's less than idea<br> <kbabbitt> s/idea/ideal/<br> <kbabbitt> astearns: and we'd have to add additional syntax for this case in masonry to get better behavior<br> <TabAtkins> minmax(100px, max-content) <--- works today in grid (equivalent to just 100px), Masonry should ideally be able to do it "right".<br> <kbabbitt> ... and if we have the inconsistency to use the current syntqx to get the better behavior in masonry, then in order to backport that better behavior we'd need new syntax for grid?<br> <TabAtkins> minmax(min-content, max-content) <---- illegal today in Grid (but maybe can have something defined for it), works in Masonry<br> <astearns> ack astearns<br> <astearns> ack fantasai1<br> <astearns> ack fantasai<br> <kbabbitt> fantasai1: there's several different behavior you might want out of repeating minmax<br> <kbabbitt> ... one is use max size you can get & repeat that number of oclumns<br> <kbabbitt> ... distribute extra space some other way<br> <lea> TabAtkins: is the 2 intrinsic size case something that comes up in practice?<br> <lea> (for masonry)<br> <kbabbitt> ... another is repeat min size and extra space gets absorbed as you approach max size<br> <kbabbitt> ... but never goes beyond that max<br> <kbabbitt> ... both are reasonable things you might want<br> <TabAtkins> lea: yes, because, say, `min-content` === minmax(min-content, min-content)<br> <kbabbitt> ... currently grid has a little bot of both involved<br> <kbabbitt> ... if you do 2 fixed size or have max and fixed isze, you use max and find some other way to dsitrubute space<br> <TabAtkins> (all single-value track szies are equivalent to doing a minmax() with both arguments the same<br> <TabAtkins> )<br> <kbabbitt> ... if you have a fixed minimum, then you count with min and extra space gets absorbed by column as you approach maximum<br> <kbabbitt> TabAtkins: still different issue of can we make minmax more powerful<br> <kbabbitt> ... question is what does minmax do by default?<br> <kbabbitt> fantasai1: but what you argue is that author will always want max size<br> <kbabbitt> TabAtkins: not arguing that<br> <kbabbitt> ... minmax has a behavior we are defining in masonry with double intrinsic size<br> <kbabbitt> ... and we should carry that over to mixed as well<br> <kbabbitt> ... what behavuior minmax has is irrelevant, what matters is we define behavior fo rintrinsic sizes in masonry we should be consistent<br> <kbabbitt> alisonmaher: agree with TabAtkins, we can backport this later<br> <kbabbitt> ... can we resolve now and make a change later?<br> <lea> q+<br> <kbabbitt> TabAtkins: among the people that have paid sufficient attention, I think there's leaning towards making masonry self-consistent rather than grid-consistent<br> <kbabbitt> ... can we resolve on that?<br> <astearns> ack lea<br> <kbabbitt> fantasai1: lea is on queue<br> <kbabbitt> lea: it seems like we have 2 possible resolutions<br> <kbabbitt> ... none are idea<br> <kbabbitt> s/idea/ideal/<br> <kbabbitt> ... how do they differ in terms of what we can do down the line?<br> <kbabbitt> ... much more comfortable if we can fix it later vs being stuck<br> <kbabbitt> ... as an author I've been bit by combining intrinsic and non-intrinsic sizes in grid and have it not work as expected<br> <kbabbitt> ... apprehensive of having same wart in masonry<br> <kbabbitt> ... is there any path into fixing this in grid?<br> <kbabbitt> ... not just porting behavior, but is there any path to fixing this properly in grid at some point?<br> <kbabbitt> ... with syntactic opt-in<br> <kbabbitt> ... it feels to me we need more data<br> <kbabbitt> ... anything we resolve here we're going to be stuck with<br> <kbabbitt> ... not that we can resolve and re-examine down the line<br> <kbabbitt> ... this is a fork<br> <kbabbitt> TabAtkins: correct this is something we need to decide, core layout behavior<br> <kbabbitt> ... neither is any different in terms of how we're locked in<br> <kbabbitt> ... new behavior would require syntactic switch regardless<br> <kbabbitt> ... don't think we need any particular data, just a desing question we need to answer<br> <kbabbitt> ... doubt there's any meaningful data we could gather<br> <kbabbitt> ... just a question of what behavior we want in masonry<br> <kbabbitt> lea: seems reasonable that consistency with broken behavior is not a desirable goal<br> <kbabbitt> fantasai1: [summarizing on whiteboard]<br> <kbabbitt> TabAtkins: what I think is useful to look at, is what's behavior of fixed + minmax in grid vs masonry<br> <TabAtkins> minmax(100, max-content) and minmax(min-content, max-content)<br> <kbabbitt> ... what the above do in grid and masonry<br> <kbabbitt> ... one is determined already in grid<br> <kbabbitt> ... one is determined already in masonry<br> <kbabbitt> fantasai1: [continues making chart on whiteboard]<br> <astearns> mm(<length>, <length>)<br> <astearns> mm(<length>, auto)<br> <astearns> mm(auto, <length>)<br> <astearns> mm(auto, auto)<br> <kbabbitt> (where `mm` expands to `minmax`)<br> <astearns> and the differences are whether grid and masonry count each of these by min, or max<br> <kbabbitt> TabAtkins: there's a `1` in the table which is currently illegal in grid, we can define whatever<br> <kbabbitt> ... question is, what do these cases (pointing) do in masonry<br> <kbabbitt> fantasai1: let me explain this because there's several things going on<br> <kbabbitt> ... I think we need to take them all together<br> <kbabbitt> ... question of what we do in grid with minmax auto auto for auto repeater<br> <SebastianZ1> I believe minmax(auto, auto) doesn't really make much sense for authors.<br> <kbabbitt> ... question where one case is fixed and one intrinsic, do we calculate intrinsic through and thcomare and tae result<br> <kbabbitt> ... or ignore intrinsic<br> <TabAtkins> SebastianZ1: minmax(auto, auto) is exactly equivalent to just "auto"<br> <kbabbitt> ... let me walkt through chart<br> <TabAtkins> SebastianZ1: so it's something authors "write" already<br> <astearns> https://usercontent.irccloud-cdn.com/file/DqXUz9TL/IMG_2299.png<br> <kbabbitt> ... with double length take max of two in both grid and masonry<br> <kbabbitt> ... if you have 1 length and 1 intrinsic, in grid currently you take min value<br> <kbabbitt> ... which is length<br> <kbabbitt> ... and in masonry I'm proposing we do the same things<br> <kbabbitt> ... so track list behaves both in both models<br> <kbabbitt> ... TabAtkins is saying use heuristic to calculate through, do that only for masonry not for gird<br> <kbabbitt> ... when you have auto and then lenght in max position, in grid you take that max ignoring what ayuto would resolve to<br> <lea> q?<br> <lea> q+<br> <astearns> ack fantasai<br> <kbabbitt> ... I propose do same thing in masonry so you have same track listing<br> <TabAtkins> q+<br> <kbabbitt> ... keep in mind this auto is a heuristic, not necessarily actual auto you would resolve with mix of item sizes<br> <astearns> https://lists.w3.org/Archives/Public/www-archive/2025Aug/0001.html<br> <kbabbitt> ... final row, if you have auto and auto, that's the new thing<br> <kbabbitt> ... calculate both through and take max<br> <kbabbitt> ... again a heuristic, not bigger than actual maximum<br> <kbabbitt> ... TabAtkins Original proposal was to always resolve to 1<br> <kbabbitt> ... there is also 3 different behaviors an author could potentially want<br> <kbabbitt> ... out of 2 different sizes<br> <kbabbitt> ... one is min size count and then grow after calcing columns<br> <kbabbitt> ... other is to figure out what's the max size and then count based on that<br> <kbabbitt> ... distribute extra space between columns, left, right, or whatever<br> <SebastianZ1> q+<br> <kbabbitt> ... we should probably introduce keywords, both are potential behaviors authors might want<br> <astearns> ack lea<br> <kbabbitt> lea: stepping back, thanks fantasai1 for summary<br> <kbabbitt> ... it looks like when authors combine lengths with intrinsic ketywords in minmax in grid<br> <kbabbitt> ... they're basically ignored<br> <kbabbitt> fantasai1: count of columns is based on length<br> <kbabbitt> ... once you figre ouyt column count, then you place items and resolve sizes with regard to what's inside that column<br> <kbabbitt> ... and autos all resolve<br> <kbabbitt> astearns: but that's not quite right<br> <kbabbitt> alisonmaher: we do ignore for counts<br> <kbabbitt> TabAtkins: this question is entirely about column count<br> <kbabbitt> fantasai1: but then you do actual sizing<br> <kbabbitt> TabAtkins: in both grid and masonry<br> <kbabbitt> fantasai1: depending on other sizes in track listing, size we use for count is not necessarily size you get at end<br> <kbabbitt> fantasai1: if every item in your grid is the same size, and this is the ony track listing you have, sizes we calculate here by any of these means is size of track<br> <astearns> ack TabAtkins<br> <kbabbitt> TabAtkins: in your table fantasai1<br> <kbabbitt> ... you have different answers for grid double intrinsic in our 2 columns<br> <kbabbitt> ... those should be the same<br> <kbabbitt> ... ? define something for it<br> <kbabbitt> ... they need to be identical because whatever we decide there<br> <kbabbitt> ... which is not question for this issue<br> <kbabbitt> ... it would be cool to define that behavior in both cases<br> <kbabbitt> ... they should not look different in those 2 cells, our 2 cells should be identical<br> <kbabbitt> ... the meaningful distinction fantasai1 draws between min and max in brackets vs in parens for current behavior which is pick the larger of the two<br> <kbabbitt> ... they look similar but are substantially different behaviors<br> <kbabbitt> kbabbitt: angle brackets<br> <astearns> ack SebastianZ<br> <kbabbitt> fantasai1: angle brackets vs parens is significant<br> <kbabbitt> SebastianZ: tend slightly to fantasai1's porposal<br> <kbabbitt> ... seems slightly more consistent and what I would expect as an author<br> <kbabbitt> TabAtkins: SebastianZ, as a dev, do you think repeat with auto and repeat with 100px auto should be substantially different in behavior, or close but one has a min with 100px?<br> <TabAtkins> auto vs minmax(100px, auto)<br> <kbabbitt> ... should those cases be substantially different or just slightly different?<br> <lea> q+<br> <kbabbitt> SebastianZ: I think they should be substantially different<br> <kbabbitt> ... in first case you use the intrinsic size of element, in other, you consider 100px in minmax<br> <kbabbitt> TabAtkins: in second one, you are not considering intrinsic size at all in fantasai1's proposal<br> <kbabbitt> ... you're okay with auto using intrinsic sizes, and 100px auto ignoring intrinsic size?<br> <kbabbitt> SebastianZ1: yes<br> <kbabbitt> TabAtkins: don't agree that's the behavior I want<br> <astearns> ack lea<br> <kbabbitt> lea: I think I'm tending to agree with TabAtkins<br> <kbabbitt> ... if auto isn't there and we don't want to discard author intent, 100px is just a bound<br> <TabAtkins> s/I want/I want, but wanted to make sure it was the behavior you wanted/<br> <florian> q?<br> <florian> q+<br> <kbabbitt> ... I don't want my track to be smaller than that<br> <kbabbitt> ... does seem weird they have substantially different behavior<br> <kbabbitt> ... TabAtkins's proposal seems closer to what I'd expect<br> <kbabbitt> fantasai1: but not consistent between grid and masonry<br> <TabAtkins> you already have a different beahvior in `repeat(auto-fill, auto)` between the two<br> <kbabbitt> ... when teaching, with TabAtkins" proposal you say in grid X happenbs, in masonry Y happens<br> <SebastianZ1> q+<br> <kbabbitt> lea :I get it but that seems more surprising<br> <kbabbitt> ... how many authors are trying grid and masonry at same time?<br> <kbabbitt> ... seems weird they'd get different number just so it's consistent<br> <kbabbitt> ... wouldn't expect one of 2 values to get discarded<br> <kbabbitt> fantasai1: but that's what happens in grid<br> <kbabbitt> lea: but if we can not break expectations in masonry...<br> <astearns> ack florian<br> <kbabbitt> fantasai1: setting expectation for grid<br> <florian> q-<br> <kbabbitt> florian: discarding one value for purpose of colimn ciount but not for sizing<br> <kbabbitt> ... not completely being ignored<br> <kbabbitt> ... why would you even write this, but you do care<br> <kbabbitt> lea: don't have a strong opinion. both seem reasonable, both have flaws<br> <kbabbitt> ... leaning slightly towards what TabAtkins is porposing<br> <kbabbitt> ... both make reasonable tradeoffs<br> <astearns> ack SebastianZ1<br> <kbabbitt> ... see fantasai1's point as well<br> <astearns> ack SebastianZ<br> <kbabbitt> SebastianZ1: maybe propose resolution, if one group leans one way one group leans towards another<br> <kbabbitt> ... maybe get experimental impl, see if it works out?<br> <kbabbitt> TabAtkins: I doubt taking this back to the issue will meaningfully result in any change in behaviors<br> <kbabbitt> ... I propose we straw poll for answer and ask for objections<br> <kbabbitt> ... would like to hear miriam's take on this as well<br> <kbabbitt> ... helpful we clarified different pieces and how they fit together<br> <lea> +1 in hearing miriam's take.<br> <kbabbitt> s/... would/fantasai: would/<br> <lea> (Also, as a general point, when both options seem subotpimal, it always makes me wonder if we're missing a third option)<br> <kbabbitt> fantasai1: and we can come back to this issue when more people can dial in<br> <kbabbitt> ... and summarize where we're at<br> <kbabbitt> astearns: would you be fine with that TabAtkins?<br> <kbabbitt> TabAtkins: I'm okay with it with a fixed flag<br> <kbabbitt> ... when we have miriam's opinion in 2 weeks, we decide on it<br> <kbabbitt> ... we've had problems in the past where weve run masonry issues into the ground and not reslved<br> <kbabbitt> alisonmaher: I'm fine, if this issue can be reopened<br> <kbabbitt> fantasai1: we can revisit this once we have larger audience<br> <kbabbitt> astearns: we will revisit this one and move on]<br> <kbabbitt> ... will we get into same morass with other repeat issues?<br> <kbabbitt> fantasai1: they're different<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12573#issuecomment-3199812988 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 19 August 2025 08:43:29 UTC