[css-grid-3][masonry] Enabling repeat(auto-fill, auto) #10915
Labels
Comments
|
Copying over the key part of Tab's comment:
|
|
See also earlier discussion in #9321 |
|
Yeah, my original draft's constraints meant that auto-sized repeats could be done completely correctly; there was no chance of spans covering different types of tracks. (You still had to ignore placement, of course, but it had less of an effect.) Adapting that into this draft means that I can at best be heuristic. If you've only got span-1 items, it works correctly; if you do have all the tracks identical (which is what the initial value gives), it works correctly. It's only when you have a mixture of track sizes and spanning items that the heuristics have to kick in, and I think they still give a reasonable result. |
|
We don't believe that |
|
@jensimmons I think you're referring to the |
|
The CSS Working Group just discussed
The full IRC log of that discussion<kbabbitt> fantasai: when we were discussing masonry proposals, one of the points in the display:masonry proposal was that we can have syntax not allowed in grid properties<kbabbitt> ...and use that to do cool new stuff <kbabbitt> ... one of the cool new things advocated for was repeat(auto-fill, auto) <kbabbitt> ... which we don't allow in grid because grid figures out how many tracks exist before figuring out their sizing <kbabbitt> ... but in masonry we have to figure out the track sizing before we can do placement <kbabbitt> ... so we have this rule where we size the tracks as if every auto placed item was placed in the track <kbabbitt> ... and that allows us to resolve the sizes of tracks before doing actual placement <kbabbitt> ... by doing that, it means we can resolve track sizes without knowing which items are placed in them <kbabbitt> ... so we could in theory do track sizing even before we know how many tracks there are <kbabbitt> ... so that would enable repeat(auto-fill, auto) <fantasai> repeat(auto-fill, auto) <kbabbitt> ... which figures out how many tracks you could maybe fit <kbabbitt> ... by doing the sizing as if all items were in this auto track, sizing it, then using resulting size to figure out number of repetitions <kbabbitt> ... this issue is about, should we try to add something like this to grid track sizing in general <kbabbitt> ... and how do we feel about questions around explicit placement <kbabbitt> .. and the fact the auto we use to calculate repeats is not the same as auto we might set the track at <kbabbitt> jensimmons: one question I'd love to hear from rachelandrew or others on <kbabbitt> ... is this really useful to authors? <kbabbitt> ... I don't think it is and can explain why but would like to hear from those who think it is useful <kbabbitt> TabAtkins: I think that it's useful to have by default a masonry ... so long as your elements are reasonably sized by themselves <kbabbitt> ... e.g images with natrual sizes <kbabbitt> ... having default behavior to declare a masonry container be: give me as many columns as I need for these children <kbabbitt> ... seems like most useful default absenty anything else <kbabbitt> ... there are cases where it won't work e.g. if it's all text <kbabbitt> ... in a lot of cases you will, e.g. explicitly sized elements <kbabbitt> ... you can always adjust from there if needed <kbabbitt> ... but it will at least be a decent answer that looks like a masonry right away <kbabbitt> fantasai: we have 2 issues <kbabbitt> ... separate issues <kbabbitt> ... what should initial value be is next issue <kbabbitt> ... this issue is whether we should have this capability at all <jensimmons> q+ <astearns> ack fantasai <Zakim> fantasai, you wanted to clarify the issue scope <kbabbitt> ... which is different from inital value <kbabbitt> ... I thnk there are use cases where this would be useful <kbabbitt> TabAtkins: I think this is a useful value because it gives an okay initial result <astearns> q+ to ask what happens when it won’t work <kbabbitt> jensimmons: I do understand what we're talking about, whether it's initial value or not, I question whether it's worth doing <kbabbitt> ... if it's easy to do, won't hurt anything, if it's hard. not worth it <kbabbitt> ... sounds amazing on its face <kbabbitt> ... where you put auto, either intentionally or by defeault <kbabbitt> ... and you don't have to worry about defining track sizes <kbabbitt> ... or this many tracks between these sizes <kbabbitt> ... instead you can automatically get right amount <kbabbitt> ... but when I dug into this, it was complicated enough I couldn't figre it out by myself <kbabbitt> ... fantasai and I wanted to write about it <kbabbitt> ... one of the hardest things I've had to write about, to wrap my head around what auto does <kbabbitt> ... truth is it doesn't do much <fantasai> s/about it/about it, and it took many days/ <kbabbitt> ... great that you don't have to worry about track definition <kbabbitt> ... but most of the time, author is still going to have to go in and size all the content <kbabbitt> ... which takes higher skill and takes longer <miriam> q+ <kbabbitt> ... more fragile to do that way <kbabbitt> ... does depend on type of content <astearns> ack jensimmons <kbabbitt> ... doesn't work for a paragraph because it will just unfutrl and take 100%of containing block <kbabbitt> ... will work on text that does not wrap <fantasai> Example: https://webkit.org/wp-content/uploads/image7-megamenu-light.png <kbabbitt> ... one of our demos was a mega menu of all menus <kbabbitt> ... as long as no phrases wrap it would automatically make columns <lea> q? <fantasai> s/unfutrl/unfurl/ <kbabbitt> ... images are normally bigger than the stuff ? end up on thepage <kbabbitt> ... made smaller with CSS <kbabbitt> ... not common anymore to put natrual size of image on page <kbabbitt> ... often it ends up as a 1x image <kbabbitt> ... will look really bad on modern screern <iank_> fwiw the menu case in the webkit blog doesn't actually work the `max-contrent` in the repeater gets resolved as zero `grid-template-columns: repeat(auto-fill, minmax(max-content, 24ch));` <kbabbitt> ... I think it sounds like this amazing tool but when we looked at the code in depth, we realized it's useful 5% of the time <kbabbitt> ... 95% of the time author will get a mess <kbabbitt> ... and will need to go size all of the content manually <kbabbitt> ... so why? better to just define masonry track <kbabbitt> astearns: what is the failure mode? when it doesn't work, then what? <astearns> ack astearns <Zakim> astearns, you wanted to ask what happens when it won’t work <kbabbitt> TabAtkins: depends what you mean by fail <iank_> q+ <kbabbitt> ... if there are e3lements full of text with no reasonable isze, you get 1 track <kbabbitt> astearns: because 1 element takes up all room anyway <kbabbitt> jensimmons: a lot of times you end up with 1 column <kbabbitt> ... but could also have >1 column but width is not what you want <kbabbitt> ... width of column is width of shorter string of text <kbabbitt> ... 2 column s wehre e.g. teaser text unfurls to 1 line in 2 columns <kbabbitt> ... each width of longest string of text inthat column <kbabbitt> ... or columns with images taht arte all different sizes <kbabbitt> ... all at 1x now .look pixelated, look blurry <kbabbitt> ... each column is width of widest image at 1x in taht column <kbabbitt> .. other images in that column could be narrower <kbabbitt> ... file is not big enough to take up whole space <kbabbitt> ... widest one will make width of column, others will be blurry and look weird <astearns> ack miriam <kbabbitt> miriam: have some of same concerns as jensimmons <kbabbitt> ... I almost never use auto when I'm sizing columns in grid <kbabbitt> ... byut often use it when sizing rows <kbabbitt> ... we do allow a row based version of masonry? <kbabbitt> TabAtkins: yes <kbabbitt> miriam: that's the place I coul dpotentially see it being useful <kbabbitt> ... in those failure cases how explicit do I have to get to fix it? <kbabbitt> ... I have cards with images that are too big with wrapping text <kbabbitt> ... how explicit do I need to be, just max-width? <kbabbitt> TabAtkins: depends what you're trying to do <kbabbitt> ... might set a number of masonry columns as flexes <kbabbitt> ... might set repeat widtyh <kbabbitt> fantasai: miriam knows how to set up correct tracks, was asking what happens if she uses this feature <kbabbitt> miriam: in order to get some reasonable behavior form auto, if I have images that are big and text that wraps in cards <kbabbitt> ... how explicit do I ned to be on each card to make this useful? <kbabbitt> TabAtkins: should be just max-width <kbabbitt> fantasai: no it won't <kbabbitt> ... typically when you're trying to craete columns <kbabbitt> ... say I want many columns with width based on size of conten <kbabbitt> ... except I want to shirnk content so I set max-wdith 200px <kbabbitt> ... and I have a container that's 700px <kbabbitt> ... then I will say I can fit 3 columns here <kbabbitt> ... so I create 3 columns but then the content is never going to grow to fill... <kbabbitt> ... if I said 3 column sI would difined 700px by 3 <kbabbitt> ... the layout I want is 233px columns <kbabbitt> .. cards should be 233px each <kbabbitt> ... ignoring gaps <TabAtkins> (233px is assuming the deffault "stretch" alignment) <kbabbitt> ... but I won't get that because max-width is 200px <kbabbitt> ... so my cards will not grow to fill that extra 33px <kbabbitt> ... won't get the stretychiness you want <lea> I'm not sure I grasp all the details of this issue so feel free to ignore this if not relevant, but being able to delegate the grid definition to grid items (via `min-*`/`max-*`) instead of having to define everything on the grid container is something I have often wished was possible (and a reason folks reach for flexbox even for some grid-like use cases). It sounds like `repeat(auto-fill, auto)` allows exactly that (?) <kbabbitt> jensimmons: there's a drawing of this in the webkit article <TabAtkins> lea, it does (subject to the constraints of doing so, which elika is outlining) <kbabbitt> jensimmons: columns are squishy but images have fixed max size <kbabbitt> ... so you end up with gray space <kbabbitt> ... [as seen in example] <kbabbitt> astearns: how much would miriam need to do? <kbabbitt> fantasai: we figured out something extremely hacky which we would not want to recommend <lea> Thanks TabAtkins! I've also often needed `minmax(auto, 1fr)` or `minmax(1fr, auto)` which never seems to work (though I haven't followed those specs so no idea if that's spec or implementation) <kbabbitt> ... takes advantage of how percentages resolve and don't in different parts of algorithm <kbabbitt> ... weird stuff we could figure out because I know layout algo <kbabbitt> jensimmons: got to a place where explicitly writing track size was way easier <astearns> q? <kbabbitt> fantasai: overall I think what we found is that this auto track repeat idea for cards, images, ... <kbabbitt> ... doesn't really work <kbabbitt> ... at the point you figure out how to make it work, you should have just set track size directly <kbabbitt> ... is useful for this onscreen example <kbabbitt> ... navigation menu <kbabbitt> ... with narrow or wider columns depending on text size <kbabbitt> jensimmons: thi sisn'r right diagram because all column sare same width <kbabbitt> fantasai: this is the right diagram <kbabbitt> jensimmons: (retracts comment) <kbabbitt> jensimmons: all of these columns will be same width as longest phrase of text <kbabbitt> ...a longer phrase will make all columns wider <kbabbitt> miriam: I can see some cases where this might be useful <kbabbitt> ... seems pretty limited <TabAtkins> (i do have a followup, but maybe it can wait until later in the queue) <kbabbitt> .. curious if there's a smarter auto we can do <kbabbitt> ... smarter auto sounds great <ethanjv> +1 to miriam <kbabbitt> ... if there's a way to get ... with the images it's not going to work <kbabbitt> ... don't see a lot of usefulness to it but that gets to next issue <astearns> ack fantasai <TabAtkins> q+ <kbabbitt> fantasai: one of the other things to point out here is that for grid we size columns depending on what is placed in them <kbabbitt> ... even for masonry there are rules about explicit placement that impact columns differently <kbabbitt> ... we're assuming in this calc that there's no explicitly placed items <kbabbitt> ... we have to be conservative ie. big enough to accommodate everything <kbabbitt> ... that's a different algo or wider resulting algo than track sizing algo <kbabbitt> .... even if we want to do something like this, another possibility is to give it another keyword <kbabbitt> astearns: "big enough for everything" value <kbabbitt> fantasai: max-content-evenly <ethanjv> can we consider auto to resolve repetitions as if it was sized under min-content? <jensimmons> The article that we were just looking at is here: https://webkit.org/blog/16026/css-masonry-syntax/#:~:text=Extending%20Masonry%20with%20repeat(auto%2Dareas%2C%20auto) (And that link jumps to the right section) if you want to see more details. <astearns> ack iank_ <kbabbitt> iank_: the megamenu demo doesn't actually work as expected <kbabbitt> ... when it's resolving auto repeaters it treats max-content as 0 <kbabbitt> ... so you get column sof e.g 24ch <kbabbitt> ... it just so happens that content doesn't exceed 24ch <kbabbitt> ... but if a different language did exceed it, you would get overflow <bkardell> s/column sof /columns of <kbabbitt> ... which isn't desirable <kbabbitt> ... so you can't carefully construct your grid-template-columns to satisfy that case <kbabbitt> ... I think miriam, on your case <kbabbitt> ... adding max-wdith on images probably isn't the right thing <kbabbitt> ... what you want is max-width on content wrapper <kbabbitt> ... there are a lot of masonry demos out there with e.g. 600px content 3 columns <kbabbitt> ... disagree it isn't useful for that case <miriam> right, justify-content helps with the results <kbabbitt> ... would be sad to drop this feature, think a lot of devs would reach for this initially <TabAtkins> rows was mirian's point fwiw <kbabbitt> ... to TabAtkins' point for rows this is very useful <astearns> q? <astearns> ack TabAtkins <kbabbitt> TabAtkins: the images leaving leftover spae example <kbabbitt> ... does show that if you are stretching columns which happens by default <astearns> s/spae/space/ <kbabbitt> ... and still expecting content to fully fill them you may not get ideal result <kbabbitt> ... but if you set max-width 200px and expect 200 to be max width <kizu> q+ <kbabbitt> ... and column sare wider than that <kbabbitt> ... still fine because you use alignment to move columns around <kbabbitt> ... or center in colunms or whatever <kbabbitt> ... and if that is not what you want you still want things to be able to grow more than 20ppx <kbabbitt> ..just means you want to be using track sizing at that point <kbabbitt> ... nothing wrong with that but based on content you have, lea pointed in chat that that is useful and apparently causes people to reach for flex intead of grid <kbabbitt> ... even though grid would be better, would be unfortunate for masonry not to address this <kbabbitt> ... finally the initial value if we don't have this is "none' tracks <kbabbitt> ... which generates 1 implicit track <kbabbitt> ... which is almost never what you want <kbabbitt> ... degenerate case <astearns> ack kizu <kbabbitt> kizu: I agree that for row direction it can be useful <kbabbitt> ... not as much in column direction <kbabbitt> ... could have text things that don't fully grow <kbabbitt> ... unstable in column direction, fragile <kbabbitt> .... however I was thinking about this for images <kbabbitt> ... this is something where we might want something similar to flex-basis <kbabbitt> ... some width that defines this that you're allowed to ?> <kbabbitt> ... for example if we have 4 inputs right now, they have some magic built in <kbabbitt> ... they have some kind of basis width which is not phrased any other way in css <kbabbitt> ... maybe this is something that could be more general <kbabbitt> ... another intrinsic dimension of an element we could define <astearns> ack fantasai <Zakim> fantasai, you wanted to respond to Tab's example <kbabbitt> .. could be used here and some other places <kbabbitt> fantasai: re: TabAtkins - while yes you could distribute space with alignment properties <kbabbitt> .. very unusual to want to do that <kbabbitt> ... typically want to dsitribute into content itself <kbabbitt> ... so in terms of is this useful? yes <kbabbitt> ... I think there are cases you might want it <iank_> How "mega-menu" renders with a large string. https://usercontent.irccloud-cdn.com/file/gJAPFlqG/Screenshot%202025-04-02%20at%2012.48.21%E2%80%AFPM.png <kbabbitt> ... should it be initial value? no <kbabbitt> ... while you get a masonry layout immediately, the direction you need to tweak things in, it guides you in the wrong idrection <kbabbitt> .. encourages you to tweak item sizing but that's not going to get you where you want <kbabbitt> ... by using `none` we make it obious that track sizing will get you to where you want to go <miriam> Unusual to justify items, but not unusual to justify content (in my experience) which also gets you there <kbabbitt> TabAtkins: don't know I agree it guides you to using sizes <kbabbitt> ... don't think it guides you either way <fantasai> +1 to kizu <kbabbitt> ... track sizing and item sizing are not used yet <kbabbitt> ... either is available to you <iank_> you could make the argument that the normal-value for justify-content to be center <kbabbitt> ... container sizing might be what you reach for first <kbabbitt> ... it can go either way and either is potentially doable <kbabbitt> ... but 1 masonry track for default display is never what you want <jensimmons> q? <kbabbitt> ... whereas auto may be what you want <kbabbitt> ... and dependoing on content often what you want <astearns> ack lea <miriam> q+ <kbabbitt> lea: I definitely have stumbled many times on wanting to set layout constraints on grid items <kbabbitt> ... also on flex. settin gon flex items <kbabbitt> ... don't have to make assumptions about children structure <kbabbitt> ... hide contents and set constratins on items to be sized <kbabbitt> ..; which often feels more natural <kbabbitt> ... don't have an opinoin on whether it should be default though TabAtkins's argument seems convincing <TabAtkins> (kizu's point about the need for a flex-basis analog is compelling to me) <astearns> ack miriam <kbabbitt> miriam: think I'm coming artound to utility of this even if limited <kbabbitt> ... as a default <kbabbitt> ... but still interested onpushing on what kizu was saying <kbabbitt> ... and what lea was getting aty with grid <ethanjv> q+ <kbabbitt> ... can we improve auto somewhat? <kbabbitt> ... as a basis for items <kbabbitt> ... so we have a target to aim for without using a min or max that will be a final constraint <iank_> q+ <kbabbitt> ... fantasai might be right that it's unuitual to use justify-utems to get rid of space <jensimmons> q+ <kbabbitt> ... but it's common to use justify-content <astearns> ack ethanjv <TabAtkins> (a 'justify-content:center' to put the extra space on the outside, for isntance) <kbabbitt> ethanjv: following on what miriam said <kbabbitt> .. worth exploring that auto behavior can be improved <kbabbitt> ... cirrently wackiness of items using max width and ? as acombination to expand to columns <kbabbitt> .. could be mitigated by using auto behavior to ??? <kbabbitt> ... in the case the webkit blog post mentioned <kbabbitt> ... wackiness because specified max width but want stratch behavior <kbabbitt> ... could explore min-width to auto size content <kbabbitt> ... explore in dfferent auto behavior <kbabbitt> s/min-width/min-content/ <astearns> s/min-width/min-content/ <astearns> ack iank_ <kbabbitt> iank_: posted a screenshot of how safari renders the menu case with a long string <kbabbitt> ... you get content that's ? pretty quickly <kbabbitt> ... this is particularly bad fro i18n <kbabbitt> ... esp if people want to do that type of repeater <kbabbitt> ... you could also argue that normal value for justify-content is center <kbabbitt> ... if this is the default <kbabbitt> ... think that will match a lot of cases where people want this <TabAtkins> that's an interesting idea <astearns> ack jensimmons <kizu> (found a CodePen that demonstrates the inputs magic that I mentioned for reference: https://codepen.io/kizu/pen/dPbQNyW) <TabAtkins> (normal -> center in masonry) <kbabbitt> jensimmons: would be interesting to find out how hard to implement <kbabbitt> ... if not hard, let's do it and see what happens <kbabbitt> .. sometimes we're surprised either way <kbabbitt> ... if it is hard don't know <kbabbitt> ... have not gone in depth thinking things in row direction <kbabbitt> ... don't want to confidently state what I think about that <kbabbitt> ... would ask that ... strongly held opinoins stated in this call <kbabbitt> ... if you really want to understand this, please read the article we wrote <kbabbitt> ... sit down with papere & notebook and thinkg through the algo and how it turns out <kbabbitt> ... still don't see where things fall in column direction except very few use cases <TabAtkins> q+ <kbabbitt> ... was surprised ,the more we dug in the worse it got <astearns> ack fantasai <iank_> q+ <kbabbitt> fantasai: one thing to point out is, the wy we calculate repetition is going to prefer items that may or may not end up in any of these ? tracks <kbabbitt> ... have to calculate number of repeats before we do any placement <kbabbitt> ... have to place explicitly placed items first <kbabbitt> ... if you have a lot of wide items in explicit track not part of repeat <kbabbitt> ... and narrow items in repeat <kbabbitt> ... algo will still have to size all of those items <kbabbitt> .. doesn't know where explicit items go until it resolves repeat number <kbabbitt> ... going to create somewhat surprising behavior <kbabbitt> .. wondering if we should give that behavior a different keyword <kbabbitt> ... to explain where this sizing goes against items regardless of where placed <kbabbitt> ... would also resolve point iank_ brought uyp <kbabbitt> ... where if you put this in a minmax right now <kbabbitt> ... repetition algo takes a fixed value to calculate the repeat and sizing <kbabbitt> ... and if you don't have an explicit value that's currently not valid <kbabbitt> ... we'd be making it valid, the ? might get weird if we don't have a keyword <astearns> ack TabAtkins <kbabbitt> TabAtkins: directly off that, wanted to make sure it was clear <kbabbitt> ... ignoring initial value question, behgavior of any auto keyword when given ? as track size <kbabbitt> ... illegal in grid because we don't know what goes where <kbabbitt> ... propose to allow in masonry because we layou items as we create callins <kbabbitt> s/callins/columns/ <kbabbitt> ...need to be more careful since algo is pretend everything is auto placed <kbabbitt> ... and we chop spanners up into pieces <kbabbitt> ... but this is the behavior for all intrinsic sizes <kbabbitt> .. so if you repeat auto fit min content <kbabbitt> ... you get same behavior except using min sizes <kbabbitt> ... if we decide we don't want to mislead people into thinking this is the sameas explicit auto size tyracks <kbabbitt> ... we'd want to do that for all auto size keywords <kbabbitt> ... and ban them in general in auto repeat functions <kbabbitt> fantasai: want to bring back the example iank_ put earlier <fantasai> repeat(auto-fill, minmax(auto, 24ch)) <kbabbitt> ... that's currently valid <kbabbitt> ... adnw euse 24ch to resolve number of repeats <kbabbitt> .. the auto that's there gets resiolved after placement in normal way <kbabbitt> ... based on content in that track <kbabbitt> .. keyworkd we're proposing to add here has different behjavior <kbabbitt> ... it's weird that taking out the max and putting auto back is going to get you something fundamentally different <kbabbitt> ... that's why I suggest different keyword, it will resolve differently <kbabbitt> TabAtkins: comfortable with that <kbabbitt> .. would like some kind of auto size auto repetition <kbabbitt> ... don't have a strong opinion on how <kbabbitt> ... if that's giving bad results more comfortable with abandoning <kbabbitt> ... want some way to say "just do the thing" <kbabbitt> ...partially for initial value but also think it's useful explicitly as well <astearns> ack iank_ <kbabbitt> iank_: re implementability - don't think it's particularly difficult <kbabbitt> ...esp with grouping of masonry items <TabAtkins> s/if that's giving/if using normal intrinsic sizes is giving/ <kbabbitt> ... within context of masonry it's not difficult <kbabbitt> ... doesn't work in grid for good reasons <ethanjv> +1 <kbabbitt> ... so it's disjoint there but relatively straightforward in masonry context <astearns> ack fantasai <kbabbitt> fantasai: another reason why it's better not to make this initial value <kbabbitt> ... and push authors to explicit track sizing <kbabbitt> ... it's a little more expensive because you have to scan items up front <kbabbitt> .. which yuou don't have to do other2wise <iank_> q+ <kbabbitt> .... other thing to say is if we're adding this, it's not going to be part of grid-template-* <kbabbitt> ... need to give it a meaning in grid as well as masonry <TabAtkins> `repeat(auto-fill, basis)`, with `masonry-basis: <'width'>` as a new property you can optionally set <kbabbitt> ... a bunch of weird things that can happen if author over constrains in both axes <astearns> s/it's not going/it’s going/ <kbabbitt> ... if they don't this can give a useful behavior even in grid <kizu> Thinking about a `repeat(sqrt(sibling-count()), 1fr)` default <astearns> ack iank_ <TabAtkins> kizu: I mean......... <kbabbitt> iank_: I would somewhat disagree that its more expensive <kbabbitt> ... often as soon as you have anything which is going to expect a min auto size or auto track or anything like that you need to group items <kbabbitt> ... so I don't think it's actually in common case more expensive <kbabbitt> ... basically with masonry we assume everything fits in every column <kbabbitt> ... as soon as you have one column thats ? <kbabbitt> ... you need to group everything into a group <kbabbitt> ... antything except fixed width tracks you need this anyway <miriam> @kizu I think `1fr` would need to be `minmax(0, 1fr)` <kbabbitt> astearns: hearing a range of opinions between this can be useful in some cases to this isn't entirely un-useful <kbabbitt> ... maybe the name needs to change? <kbabbitt> ... maybe we need an item size basis that works in all of these? <kbabbitt> ... things we need to follow up on <kbabbitt> ... not sure we're going yo get farther on this today <kbabbitt> ... people have homework to go through blog post, work out their own examples <kbabbitt> ... counter blog posts would be welcome <kbabbitt> ... should we move on to initial value? <kbabbitt> fantasai: let's give it a try <kbabbitt> astearns: do you have an alternate in mind?> <kbabbitt> fantasai: keep current one <kbabbitt> astearns: let's close this issue for now <kbabbitt> ACTION: TabAtkins to open item size basis issue <kbabbitt> ACTION: fantasai to open issue to change name |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Google's earlier Alternate Masonry Proposal—which didn't allow for mixed track sizing and constrained all content-sized tracks to be the same size—allowed
repeat(auto-fill, auto)as a track listing, computingautoas the largest [item size]/[span size].This definition doesn't work with mixed track sizes, because the amount that an item contributes to each track can differ based on what it's spanning. Filing this issue to ask if we can still add this value, and if so, what does it mean? Does it also work in grid layout?
Note: There's a separate, but related, issue about what the initial track listing should be, and whether it should be this.
The text was updated successfully, but these errors were encountered: