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 redefined to do nothing on the block axis?`, and agreed to the following:

* `RESOLVED: cbiesinger will document chrome's behavior and we will revisit`

<details><summary>The full IRC log of that discussion</summary>
&lt;fremy> Topic: why was min-content redefined to do nothing on the block axis?<br>
&lt;fremy> fantasai: since christian raised this issue, it would be good to have him on the line when we discuss this?<br>
&lt;fremy> fantasai: (this was a question)<br>
&lt;fremy> astearns: we could move to the next one to see if we can get christian on the line?<br>
&lt;fantasai> cbiesinger: ping<br>
&lt;fremy> iank_: (pinging christian on slack)<br>
&lt;fremy> (cbiesinger dialing in)<br>
&lt;fremy> &lt;br type="technical" /> ;-)<br>
&lt;fremy> astearns: cbiesinger can you summarize the issue?<br>
&lt;fremy> cbiesinger: there was a change in css-sizing spec<br>
&lt;fremy> cbiesinger: now min-content does the same as the initial value<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/3973<br>
&lt;fremy> cbiesinger: which is great for height<br>
&lt;fremy> cbiesinger: but for min-height for instance, this is a change in behavior<br>
&lt;fremy> cbiesinger: and in flexbox with auto, you can't get a specific effect that you used to get before<br>
&lt;fremy> cbiesinger: so we should probably redefine it again so that it does a different thing by property<br>
&lt;fremy> fantasai: makes sense to me<br>
&lt;fremy> dbaron: the assumption is that it was defined before<br>
&lt;fremy> dbaron: but before it wasn't clear to me what it was actually supposed to do<br>
&lt;fremy> dbaron: you have block size that is derived from the content<br>
&lt;fremy> dbaron: but it doesn't say which inline size is used to get that layout done<br>
&lt;fremy> dbaron: so in the general case, what would be that inline size?<br>
&lt;fremy> dbaron: is that a function of something else? how does it get passed in to this?<br>
&lt;fremy> cbiesinger: yay, that's true<br>
&lt;fremy> cbiesinger: the definition of the min-content block size still exists in the spec though<br>
&lt;fremy> cbiesinger: and it has this issue, so we need to fix this no matter what<br>
&lt;fremy> dbaron: sure, but I'm not sure we should have this in the spec at all<br>
&lt;AmeliaBR> min-content block size definition: https://drafts.csswg.org/css-sizing-3/#min-content-block-size<br>
&lt;fremy> cbiesinger: in the common case in a column-flexbox, it defaults to min-height, min-content<br>
&lt;fremy> dbaron: and how do you determine what that height is?<br>
&lt;fremy> cbiesinger: you use the inline size you derive from the sizing properties<br>
&lt;fremy> dbaron: so it's not really an intrinsic size, it's a specific size that depends on the layout you are in the middle of doing<br>
&lt;fremy> dbaron: so we don't really need this concept for that case<br>
&lt;fremy> dbaron: but for othogonal flows, you'd allegedly need the general case?<br>
&lt;fremy> fantasai: for orthogonal flows, you have to pick a size anyway<br>
&lt;fremy> dbaron: so, ok, regardless, we need to define very precisely that inline size<br>
&lt;fremy> iank_: is it true that in our implementation, the value is (...) ?<br>
&lt;fremy> cbiesinger: yes, the post-layout size is (...)?<br>
&lt;fremy> iank_: in our implementation, min-content and max-content were the same, and were the post-layout block size of this element, as if no other constraints were applied<br>
&lt;fremy> ^ clarifying the ... above<br>
&lt;fremy> iank_: and it works thanks to the clamping<br>
&lt;fremy> fantasai: I think it's very clear to me that the change was not correct anyway<br>
&lt;fremy> fantasai: so we should revert this edit anyway<br>
&lt;fremy> fantasai: but I agree we should also make sure we get things defined explicitly<br>
&lt;fremy> fantasai: and maybe think whether min-content and max-content should be the same<br>
&lt;fremy> dbaron: and even if they are the same, we need to define what they are<br>
&lt;fremy> dbaron: but if we don't have a first-layout pass, sometimes it happens?<br>
&lt;fremy> iank_: for min-height/max-height you do, because you clamp an existing height<br>
&lt;fremy> fantasai: so, yeah, using the default value is wrong because sometimes auto is not min-content<br>
&lt;fremy> fantasai: I can't think of a reason for blocks to want min-content != max-content<br>
&lt;fremy> fantasai: maybe for grid, we could trigger the different distributions algorithms for them<br>
&lt;fremy> fantasai: we should think about that<br>
&lt;fantasai> s/maybe/but/<br>
&lt;fantasai> It's less clear that they should be different in this case, because there are different space distribution rules for each<br>
&lt;fremy> astearns: so, I hear that we want to revert, and try to get a definition for this<br>
&lt;fremy> astearns: even if there is some scepticism we can get a definition that works<br>
&lt;fremy> dbaron: I would also not want to call them intrinsic if they are not intrinsic anymore<br>
&lt;fremy> dbaron: it seems to me we are defining something else entirely<br>
&lt;fremy> dbaron: doing some of these things require major changes in some algorithms, and I'm not sure what the use cases are<br>
&lt;fremy> cbiesinger: min-height:min-content seems useful<br>
&lt;fremy> dbaron: it is not impossible that this could take a year for us to implement, and I'm not sure this is worth<br>
&lt;fremy> dbaron: there are some existing implementations, but did we check that they match, and not are just superficially similar<br>
&lt;fremy> dbaron: I am not sure<br>
&lt;fremy> dbaron: so I don't want to take this lightly<br>
&lt;fremy> dbaron: so I would rather have a full proposal<br>
&lt;fremy> dbaron: so I can evaluate complexity, and evaluate the cost/benefit ratio<br>
&lt;fremy> dbaron: there are things that happen in gecko when you specify these things of course, but are we interop? probably not?<br>
&lt;fremy> emilio: I don't think we have impelemnted to block size that works in the block axis<br>
&lt;fremy> TabAtkins: (pointing another case that seems wrong in gecko, even in the inline axis)<br>
&lt;fremy> cbiesinger: agrees that some cases are difficult in the inline cases<br>
&lt;fremy> TabAtkins: we do use an approximation here, that was better than gecko that assumes a single-column<br>
&lt;fremy> TabAtkins: Edge had a good implementation<br>
&lt;fremy> TabAtkins: but regardless, we didn't<br>
&lt;fremy> TabAtkins: so I tend to agree that intrinsic isn't always as "intrinsic" as the name implies<br>
&lt;fremy> TabAtkins: it sometimes requires full layout<br>
&lt;fremy> fantasai: how about changing the spec to say that we want to match the `auto` height<br>
&lt;fremy> fantasai: but in the sense of `auto` that computes an height<br>
&lt;fremy> fantasai: not like in grid where `auto` sometimes means `stretch` etc<br>
&lt;fantasai> s/height/height based on the content size, rather than filling the container etc./<br>
&lt;fremy> astearns: can we resolve of reverting?<br>
&lt;fremy> dbaron: I'm uncomfortable going back to undefined<br>
&lt;fremy> astearns: but other engines don't want that current spec text<br>
&lt;fremy> dbaron: ok, but this is a can of worms<br>
&lt;fremy> dbaron: (snarky comments about multiple engines)<br>
&lt;fremy> cbiesinger: I'm optimistic we could get this interoperable<br>
&lt;fremy> iank_: for the cases that cbiesinger described, it would be easy to implement the correct behavior for that subset<br>
&lt;fremy> iank_: and we think it's useful<br>
&lt;fremy> astearns: as you implement subset, it would be nice to describe things in details, so we could find out if interop is possible<br>
&lt;fremy> fantasai: technically, the behavior we want should already exist in the engine, it might not just be called in that specific scenario<br>
&lt;fremy> fantasai: but the keyword would allow to tap in the computations that exist<br>
&lt;fremy> fantasai: possibly there are cases where you would need much more layout than engines are willing to do<br>
&lt;fremy> fantasai: but there are a lot of reasonable cases<br>
&lt;fremy> fantasai: and for those cases we should figure out what should happen and standardize that<br>
&lt;fantasai> s/to do/to do, e.g. for the width of a multiline column flexbox/<br>
&lt;fremy> astearns: basically dbaron hesitates due to lack of precise details<br>
&lt;fremy> cbiesinger: is there a particular case you think would be very hard?<br>
&lt;fremy> cbiesinger: so we could find out if we could solve that one?<br>
&lt;fremy> dbaron: intrinsic size depending on the inline, it could depend on layout optimizations<br>
&lt;fremy> dbaron: and there might be cases where we try to figure out block before inline<br>
&lt;fremy> dbaron: and all those cases seem intricate<br>
&lt;fremy> fantasai: yeah, grid has two passes for that reason<br>
&lt;fremy> fantasai: (explains how these metrics are computed already today, she thinks)<br>
&lt;fremy> dbaron: I'm worried it uses a value from late in the system, early in the system<br>
&lt;fremy> dbaron: gladly calc doesn't allow to make computations based on those values usually<br>
&lt;fremy> dbaron: but there might be cases where we do this accidentally in the algorithm<br>
&lt;fremy> dbaron: and it might cause instability/ec<br>
&lt;fremy> cbiesinger: I understand the concerns now<br>
&lt;fremy> cbiesinger: I'm still inching towards it's sufficiently useful<br>
&lt;fremy> dbaron: is is sufficiently useful that you would be willing to write a spec?<br>
&lt;fremy> TabAtkins: (proposed to meet next time he was in new-york to work on it, but cbiesinger is not based in NY)<br>
&lt;fremy> cbiesinger: I will write something<br>
&lt;fremy> cbiesinger: I can try writing a spec<br>
&lt;fremy> astearns: so, first resolution attempt, can we revert what's in the spec now?<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/3973#issuecomment-498062046<br>
&lt;fremy> (can we get a link to the change)<br>
&lt;fremy> dbaron: do we know why we made the resolution that let to this changeset?<br>
&lt;fremy> TabAtkins: I don't recall<br>
&lt;fremy> dbaron: what I don't like is that the revert will trigger chrome to revert<br>
&lt;fremy> dbaron: and that revert will be unspecced but people will rely on their behavior<br>
&lt;fremy> florian: we could have an issue in the spec<br>
&lt;fremy> Rossen: that seems overkill, we have an issue on github seems enough<br>
&lt;fremy> Rossen: I think it would be better to first get a strawman of the chrome behavior, and we can resolve the revert at that time<br>
&lt;fremy> cbiesinger: ok, sounds fine<br>
&lt;fremy> any objection to this way forward?<br>
&lt;fremy> RESOLVED: cbiesinger will document chrome's behavior and we will revisit<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-498841720 using your GitHub account

Received on Tuesday, 4 June 2019 21:00:13 UTC