Re: [csswg-drafts] [css-sizing-3] Why was min-content, etc. redefined to do nothing in the block axis? (#3973)

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>
&lt;fantasai> Topic: Why was min-content etc. to be redefined to be nothing like Block axis?<br>
&lt;Rossen__> github:https://github.com/w3c/csswg-drafts/issues/3973<br>
&lt;fantasai> cbiesinger: Seems to be disagreement between me and dbaron<br>
&lt;fantasai> cbiesinger: For a long time min-content/max-content/fit-content were defiend to work in the block axis<br>
&lt;fantasai> cbiesinger: to be the size the item would have if it weren't explicitly sized<br>
&lt;fantasai> dbaron: Size at what width?<br>
&lt;fantasai> cbiesinger: I know that's your objection to this<br>
&lt;fantasai> cbiesinger: Chrome had implemented this<br>
&lt;fantasai> cbiesinger: This is also essentially the same size that Flexbox uses for min-height: auto<br>
&lt;fantasai> cbiesinger: At one point spec was changed to say that block axis just computes to auto, and Chrome removed it<br>
&lt;fantasai> cbiesinger: However I think this is a useful thing to have<br>
&lt;fantasai> cbiesinger: Intrinsic size in the block axis at the specified width<br>
&lt;fantasai> cbiesinger: I would like to have that feature back<br>
&lt;fantasai> cbiesinger: discuss.<br>
&lt;fantasai> dbaron: You said Chrome implemented it. I'd like to see the definition of what Chrome implemented<br>
&lt;fantasai> TabAtkins: In particular our resolution was for you to tell us what you did so we can look at it :)<br>
&lt;TabAtkins> "Leaving the issue open to: hopefully get some info from @cbiesinger as he promised ^_^"<br>
&lt;fantasai> cbiesinger: Can write it up, but should I talk about it? or write it?<br>
&lt;fantasai> dbaron: I think there are a bunch of gaps in the specs, want to know how you would fill in the gaps<br>
&lt;heycam> fantasai: in the block axis, by saying it becomes auto, we're saying it becomes the max-content size<br>
&lt;heycam> ... the max content size, min content size, and auto size, are exactly the same<br>
&lt;heycam> cbiesinger: it doesn't work for min/max-height this doesnt work right now<br>
&lt;heycam> fantasai: and in that case, defining them to be teh same in the spe cdoesn't cause any problems<br>
&lt;heycam> dbaron: except the auto height of the block is a concept at layout time after you know the width<br>
&lt;heycam> ... whereas min/max content heights dont have a width to use<br>
&lt;heycam> ... and min/max content are referecned all over these other specs without saying it's at a particular width<br>
&lt;heycam> ... a particular block has a unique min content height<br>
&lt;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>
&lt;heycam> fantasai: I'm pretty sure grid does<br>
&lt;heycam> dbaron: pretty sure most specs don't<br>
&lt;heycam> fantasai: for block, you always have a iwdth<br>
&lt;heycam> dbaron: you have many widths. available width?<br>
&lt;heycam> ... intrinsic size of an orthogonal float...<br>
&lt;heycam> fantasai: that's defined in Wriitng Modes<br>
&lt;heycam> ... WMs says if you need the width you use viewport size plus some other calculations<br>
&lt;heycam> dbaron: does it say that for intrinsic size? i think it says to do that for layout, but these are different concepts<br>
&lt;heycam> fantasai: so you want to WMs to clarify to use it for both?<br>
&lt;heycam> cbiesinger: you could say it uses the width in the current layout mode<br>
&lt;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>
&lt;heycam> cbiesinger: I don't disagree<br>
&lt;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>
&lt;heycam> ... but the problem is that in grid and flex, they have different emanings<br>
&lt;heycam> ... you get a different size, content lays out differently, in the block axis<br>
&lt;heycam> ... and being able to request those sizes and being able to use them within the context of other nested layouts is useful<br>
&lt;heycam> dbaron: but the spec right now pretends these are generic concepts across all layout systems, and not dervied from widths<br>
&lt;heycam> ... but layout systems define these all over without saying what width to use<br>
&lt;heycam> dbaron: cbiesinger and I agree that tihis is not currently defined in specs<br>
&lt;heycam> cbiesinger: are you objecting to the concept of this? or just the fact that this is currently not well defined<br>
&lt;heycam> Rossen: let's doubel down on the previous resolution<br>
&lt;heycam> dbaron: I think it's a huge arthicetctureal change for our layout code<br>
&lt;heycam> dbaron: I want it to be important and clearly defined before doing that<br>
&lt;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>
&lt;heycam> ... and I still don't know what the spec is<br>
&lt;heycam> fantasai: you need to do some intrinsic sizing in the wrong axis to get grid/table to worth with orthogonal flows<br>
&lt;heycam> ... I think the architectural changes is whether you do this or not, and you already have to do it<br>
&lt;heycam> dbaron: right now in code hte functions that compute intrinsci size don't take a width argument<br>
&lt;heycam> ... and if these things are a function of width we need to work out what width to use for every caller<br>
&lt;heycam> ... some of this is complicated because intrinsic size is recursive<br>
&lt;heycam> ... it depends on all its descendants<br>
&lt;heycam> ... in some of these non-recurisve cases it could depend on layout, but we need to say what these cases are<br>
&lt;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>
&lt;fantasai> i/fantasai: in the block axis, by saying/ScribeNick: heycam/<br>
&lt;heycam> Rossen: I agree this is a large change if you are computing intrinsci size wihtout doing layout<br>
&lt;heycam> ... might be best to close this until we have details<br>
&lt;heycam> s/close this/close the discussion today/<br>
&lt;heycam> ... Christian has the action to write this up<br>
&lt;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