- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Jan 2020 10:27:58 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Why was min-content etc. to be redefined to be nothing like Block axis?`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Why was min-content etc. to be redefined to be nothing like Block axis?<br> <Rossen__> github:https://github.com/w3c/csswg-drafts/issues/3973<br> <fantasai> cbiesinger: Seems to be disagreement between me and dbaron<br> <fantasai> cbiesinger: For a long time min-content/max-content/fit-content were defiend to work in the block axis<br> <fantasai> cbiesinger: to be the size the item would have if it weren't explicitly sized<br> <fantasai> dbaron: Size at what width?<br> <fantasai> cbiesinger: I know that's your objection to this<br> <fantasai> cbiesinger: Chrome had implemented this<br> <fantasai> cbiesinger: This is also essentially the same size that Flexbox uses for min-height: auto<br> <fantasai> cbiesinger: At one point spec was changed to say that block axis just computes to auto, and Chrome removed it<br> <fantasai> cbiesinger: However I think this is a useful thing to have<br> <fantasai> cbiesinger: Intrinsic size in the block axis at the specified width<br> <fantasai> cbiesinger: I would like to have that feature back<br> <fantasai> cbiesinger: discuss.<br> <fantasai> dbaron: You said Chrome implemented it. I'd like to see the definition of what Chrome implemented<br> <fantasai> TabAtkins: In particular our resolution was for you to tell us what you did so we can look at it :)<br> <TabAtkins> "Leaving the issue open to: hopefully get some info from @cbiesinger as he promised ^_^"<br> <fantasai> cbiesinger: Can write it up, but should I talk about it? or write it?<br> <fantasai> dbaron: I think there are a bunch of gaps in the specs, want to know how you would fill in the gaps<br> <heycam> fantasai: in the block axis, by saying it becomes auto, we're saying it becomes the max-content size<br> <heycam> ... the max content size, min content size, and auto size, are exactly the same<br> <heycam> cbiesinger: it doesn't work for min/max-height this doesnt work right now<br> <heycam> fantasai: and in that case, defining them to be teh same in the spe cdoesn't cause any problems<br> <heycam> dbaron: except the auto height of the block is a concept at layout time after you know the width<br> <heycam> ... whereas min/max content heights dont have a width to use<br> <heycam> ... and min/max content are referecned all over these other specs without saying it's at a particular width<br> <heycam> ... a particular block has a unique min content height<br> <heycam> ... if min-content and max-content are a function of width, then every spec that needs to use those concepts need to say what the width input is<br> <heycam> fantasai: I'm pretty sure grid does<br> <heycam> dbaron: pretty sure most specs don't<br> <heycam> fantasai: for block, you always have a iwdth<br> <heycam> dbaron: you have many widths. available width?<br> <heycam> ... intrinsic size of an orthogonal float...<br> <heycam> fantasai: that's defined in Wriitng Modes<br> <heycam> ... WMs says if you need the width you use viewport size plus some other calculations<br> <heycam> dbaron: does it say that for intrinsic size? i think it says to do that for layout, but these are different concepts<br> <heycam> fantasai: so you want to WMs to clarify to use it for both?<br> <heycam> cbiesinger: you could say it uses the width in the current layout mode<br> <heycam> dbaron: it's hard for me to argue this witout preparation, but the last time I went through the specs following spec links I couldn't find out how it was defined<br> <heycam> cbiesinger: I don't disagree<br> <heycam> fantasai: one thing that we are losing by defining everything ot be auto, if min/max content and auto size in block axis were always equal, it wouldn't matter<br> <heycam> ... but the problem is that in grid and flex, they have different emanings<br> <heycam> ... you get a different size, content lays out differently, in the block axis<br> <heycam> ... and being able to request those sizes and being able to use them within the context of other nested layouts is useful<br> <heycam> dbaron: but the spec right now pretends these are generic concepts across all layout systems, and not dervied from widths<br> <heycam> ... but layout systems define these all over without saying what width to use<br> <heycam> dbaron: cbiesinger and I agree that tihis is not currently defined in specs<br> <heycam> cbiesinger: are you objecting to the concept of this? or just the fact that this is currently not well defined<br> <heycam> Rossen: let's doubel down on the previous resolution<br> <heycam> dbaron: I think it's a huge arthicetctureal change for our layout code<br> <heycam> dbaron: I want it to be important and clearly defined before doing that<br> <heycam> dbaron: I think this is one of those things where you can get pretty close with a bunch of hacks, but that's not the same as following the spec<br> <heycam> ... and I still don't know what the spec is<br> <heycam> fantasai: you need to do some intrinsic sizing in the wrong axis to get grid/table to worth with orthogonal flows<br> <heycam> ... I think the architectural changes is whether you do this or not, and you already have to do it<br> <heycam> dbaron: right now in code hte functions that compute intrinsci size don't take a width argument<br> <heycam> ... and if these things are a function of width we need to work out what width to use for every caller<br> <heycam> ... some of this is complicated because intrinsic size is recursive<br> <heycam> ... it depends on all its descendants<br> <heycam> ... in some of these non-recurisve cases it could depend on layout, but we need to say what these cases are<br> <heycam> ... but I think there are cases where there are hundreds of calls to intrinsic size calculations across our code, we need to work out what to pass in<br> <fantasai> i/fantasai: in the block axis, by saying/ScribeNick: heycam/<br> <heycam> Rossen: I agree this is a large change if you are computing intrinsci size wihtout doing layout<br> <heycam> ... might be best to close this until we have details<br> <heycam> s/close this/close the discussion today/<br> <heycam> ... Christian has the action to write this up<br> <fantasai> ScribeNick: fantasai<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3973#issuecomment-577620582 using your GitHub account
Received on Thursday, 23 January 2020 10:28:00 UTC