- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Sat, 29 May 2010 10:09:21 -0700
- To: Andrew Fedoniouk <news@terrainformatica.com>
- Cc: <www-style@w3.org>
I'll answer with what I think it should be... On May 28, 2010, at 8:34 PM, Andrew Fedoniouk wrote: > It seems that I am the only person so far who have implemented > flex units as a complete system. I mean I have infrastructure already in > place to try the calc() in real environment. So here are practical questions. > > 1) Meaning of "free space". > > I am assuming that free space gets computed as: > container-inner-space - sum-of-min-widths-of-children. Container-inner-space = width of container's content box. Instead of min-widths of children, I would say that for each child it is min(max(min-width, intrinsic width), max-width). Then summed to subtract from container's content box width, yes. (In case I'm not clear to some folks, 'min(A,B)' means the lesser of A and B, and 'max(A,B) means the greater of A and B.) > So if sum-of-min-widths-of-children is greater than > container-inner-space then > 1.a) there is no free space, free space is zero; > 1.b) there is a free space but it is negative, if "yes" > then it is not a free space strictly speaking. > Good name for it anyone? > > Anyway, which one of 1.a) and 1.b) is true? 1.b) Negative free space is understandable enough to me, or you can think of it as potential overflow, perhaps. > 2) Meaning of calc(flex + fixed) > > Let's imagine that we have container with > inner width = 1000px that has single empty child A > so it has no intrinsic min/max-widths. > > ----------------------------------------------------------------- > If that A element is defined as > > A { width: calc(100px + 1fx); } > > I assume that min-widths-of-children in this case is: > > 2.a) min-width = 100px, free-space = 900px. > > So its computed width is just 1000px ? > > So that definition above is exactly (A - single child) > A { width: 1fx; min-width: 100px; } > > Yes/no? Yes, sort of. But this is only because A's intrinsic width is zero and thus can't get any smaller (it does have an initial min-width of 0). If "A" had a word or picture or something in it, and that was wider than the container, then A's width would be min(100px, container-content-width). This is similar to the margin calc thing I was trying to do, where zw pointed out the errors of my ways. If the author actually wanted A to have 1fx with a min-width of 100px, it would be better authoring practice to just write that, instead of employing calc(). But the calc() above would work if that "not-really-min-width" behavior above is what is actually wanted. This is why I was proposing a 'starting-width' property, so you could indicate this desire without having to use a less-obvious-meaning equivalent in a calc(). It seemed like this was an important and common need from those using the existing version of flexbox. > ----------------------------------------------------------------- > If A element is defined as > > A { width: calc(1100px + 1fx); } > > 2.b) min-width = 1100px, free-space = -100px so element > will not overflow as total width = 1000px; > 2.c) min-width = 1100px, free-space = 0px and element > will overflow; > > If 2.c is true then it means that free-space as a value > cannot be negative. The used width is 1000px. Because flex measurements can represent negative widths, there will be no overflow here. 2b is close to correct, but it's not really a min-width. See my explanation above. The real min-width of "A" is still zero, and a calc() value for the 'width' property does not change that. > ----------------------------------------------------------------- > Now let's add min-width constraints in our equations > A > { > width: calc(100px + 1fx); > min-width: 900px; > } > > 2.d) > min-width = 900px, > free-space = 100px and > width = 900px. Yes. > 2.e) > min-width = 900px + 100px, > free-space = 0px and > width = 1000px. No. The calc is for the width. It does not change the min-width. Anyway, I see that Tab has also answered your e-mail, so I will stop here.
Received on Saturday, 29 May 2010 17:09:57 UTC