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