W3C home > Mailing lists > Public > www-style@w3.org > June 2010

Re: [css3-flex] calc(flex) and concept of free space.

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 4 Jun 2010 09:39:49 -0700
Message-ID: <AANLkTiku3kVkmlJRUTDVcmr2xwyaqSxsWAWL-X6YL3VE@mail.gmail.com>
To: Andrew Fedoniouk <news@terrainformatica.com>
Cc: Brad Kemper <brad.kemper@gmail.com>, Zack Weinberg <zweinberg@mozilla.com>, www-style@w3.org
On Thu, Jun 3, 2010 at 9:35 PM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
>>> Seems like my question was not clear enough.
>>> Let me put it this way:
>>>
>>> <div width:1000px padding-left:1fx
>>>       box-sizing:border-box *flow:vertical*>
>>>  <div #A width:calc(700px + 1fx) />
>>>  <div #B width:2fx />
>>> </div>
>>>
>>> What would be the width of div#A ?
>>> (#B there is just for illustration).
>>
>> It's 700px, by the exact same logic in the previous version of this
>> problem.  (#B is 0px wide.)
>>
>> It would be more useful if you could explain precisely which part of
>> my explanation wasn't useful.  There's something about this case that
>> you don't get, and my explanations aren't helping, so I'd like to know
>> why, just in case it's something I'm fundamentally missing.
>>
>
> I lost you here completely, sorry.
>
> Once again. You say that here:
>
> <div width:1000px padding-left:1fx
>       box-sizing:border-box flow:vertical>
>  <div #A width:calc(700px + 1fx) />
>  <div #B width:2fx />
> </div>
>
> div#A will get width 700px and
> div#B will be 0px wide, correct?
>
> And what will be the width of content-box of outer
> div then? Please note that it is box-sizing:border-box.
>
> Either both div#A and div#B should have zero widths
> (if  content box width == 0)
> or both of them should have 700px
> (if  content box width == 700px).

Oh!  I'm so sorry, I didn't notice that you'd switched to a vertical flow.

In that case, both boxes are 700px wide, as is the content area of the
parent.  That's specified in 6.2.1.2.


>>> Ok, but it is still a problem even if you will fix that.
>>>
>>> Reading definition of the "preflex length":
>>>
>>> "The preflex size of a flexible length is the greater of the flexible
>>> length's minimum and preferred sizes."
>>>
>>> E.g. for two collapsed margins you say that this margin
>>> is using max(fixed-length, preferred-length).
>>
>> Where are you seeing that?  I never say anything like that anywhere in
>> my algorithm, nor in the more informal description of margin
>> collapsing in section 4; it's quite incorrect.
>
> Here "4. Flexibility".
> <quote>
>  If one margin is "calc(20px + 1fl)" (a length with a flexibility of 1 and a
>  preferred size of 20px) and the other is "max(50px, 2fl)" (a length with a
>  flexibility of 2 and a minimum size of 50px), the collapsed margin
>  would have a flexibility of 2, a minimum size of 50px, and a
>  preferred size of 20px.
> </quote>
>
> As far as I understand all this 50px of yours will go to the preflex
> length as it is "minimum size of 50px".

Ah, okay.  The issue was the you said "fixed-length" when you meant
"min length".  I say something very specific about fixed lengths that
is *not* what you described, so I was reading it differently.


> Or there is something wrong in your definition or in my understanding
> of it.
> Is width:max(50px, 2fl) an equivalent of width:2fl, min-width:50px ?

Yes, it is exactly equivalent.


>>> This test is also about interpretation of "flexible length's minimum"
>>> "preferred length" and "preflex length" that you use.
>>
>> There is no interpretation necessary.  All of those terms are
>> precisely defined.  (If you find an ambiguity, let me know.)
>>
>
> These test's tell me better what you have in mind
> than your text for some reasons. This is probably not
> about your text per se but rather about CSS you use
> e.g. fonts and line spacing. I have no "Droid" fonts here
> and so it falls back to arial with that dense line spacing.
> And content area is fixed so I cannot make lines shorter...

Use a browser with a proper Inspector so you can change that stuff
yourself.  ^_^

(What browser are you using?  The Droid fonts are linked in via
@font-face rules from the Google CDN - you don't actually need them to
be on your computer.)


>>> So by default width of element content is not its
>>> preferred width. Probably it is better then to use
>>> something like "base width" rather than "preferred width"?
>>>
>>> In tables for example, preferred width of a column is
>>> a content width of cells in it.
>>
>> That's tables.  This is flexbox.  You can *make* the preferred width
>> be the width of the content - either use "width: calc(fit-content +
>> 1fl);" or (proposed, not yet in the draft) use "width: 1fla;".  Both
>> of these create a flexible width with flexibility 1 and preferred size
>> of the content's width.  It's just not the default way to do it.
>
> You use term "fit-content" (in your document too) that is not
> defined anywhere yet.
>
> What exactly is that "fit-content"?

Yeah, it hasn't quite been defined anywhere, but it *should* be - I
believe dbaron's got it on his plate for the future.  It's the
"intrinsic" width.  The actual definition builds on the definitions
for min-content and max-content, like so:

min-content: The width of the longest line if you take every possible
linebreak opportunity.
max-content: The width of the longest line if you don't take any
non-forced linebreak opportunities.
fit-content: max(min-content, min(max-content, available width))

Though, I suspect I have to define what the "available width" is for a
flexbox at various stages.


> E.g. for this paragraph:
> <p>100px-word 200px-word</p>
>
> Options are:
>  a) 200px - (so called min-intrinsic width)
>  b) 300px + space width (so called max-intrinsic width)

300px + space.


>> You complained about the fact that the current flexbox draft makes
>> preferred width always equal to the width of the contents.  Why are
>> you now unhappy with the opposite?
>
> Umm... I do not remember myself complaining about something like that.

It was in a much earlier email, when you were initially still very
confused about additive flexes.  The dislike may have been solely a
result of you not yet understanding it, though.


>>>>> f)
>>>>> <div width:1000px flow:horizontal >
>>>>>  <div width:calc(500px + 1fx) >some-500px-wide-text</div>
>>>>>  <div width:calc(700px + 1fx) >some-700px-wide-text</div>
>>>>> </div>
>>>>
>>>> Free space is -200px.  This gets split evenly and added to the
>>>> preferred width of each.  The first child ends up as 400px wide, the
>>>> second child as 600px wide.  The contents of both overflow.
>>>
>>> So your vision of display:box tends to follow
>>> display:block rules rather than BFC blocks like display:table-cell.
>>> Seems like your point of view is different from what Gecko/XUL
>>> is using.
>>
>> It might be different from XUL, I dunno.  It's not different from the
>> current flexbox draft, which would act in the exact same way.  That
>> is, given this markup:
>>
>> <div width:1000px display:box>
>>  <div width:500px box-flex:1>some-500px-wide-text</div>
>>  <div width:700px box-flex:1>some-700px-wide-text</div>
>> </div>
>>
>> The current flexbox draft would do the exact same thing that my
>> proposal does - the children would be shrunk to 400px and 600px wide,
>> respectively, and their contents would overflow.
>
> Try this then:
>
> <!DOCTYPE html>
> <html>
>  <head>
>   <title>Mozilla FlexBox</title>
>   <style>
>   body { font:10pt verdana; }
>   div { min-height:10px; }
>   span { border-top:2px dashed black; display:inline-block; }
>   #box1 { display:-moz-box; width:1000px; -moz-box-orient:horizontal; }
>   #box2 { -moz-box-flex: 1.0; width:500px; background:gold;}
>   #box3 { -moz-box-flex: 1.0; width:700px; background:red;}
>   #ruler100 { width: 100px; border-bottom:3px solid green; margin-top:1px;}
>   #ruler200 { width: 200px; border-bottom:3px solid green; margin-top:1px;}
>   #ruler300 { width: 300px; border-bottom:3px solid green; margin-top:1px;}
>   </style>
>  </head>
> <body>
>  <div id="box1">
>   <div id="box2"><span style="width:500px"></span></div>
>   <div id="box3"><span style="width:700px"></span></div>
>  </div>
>  <div id="ruler100" >100px</div>
>  <div id="ruler200" >200px</div>
>  <div id="ruler300" >300px</div>
> </body>
> </html>
>
> Either Mozilla does not follow their specification or their
> spec is wrong or your interpretation of their spec is not correct.

Ah, you're right.  One of those is true.  We'd have to ask Moz to see which one.


> All existing flex implementations use display:table-cell
> for flex blocks (that makes real sense) and yours is not
> for some reasons.  Probably that shift of paradigm is the main
> source of my problems to get your spec right.
>
> The idea behind of display:table-cell and flexible block is that
> they establish BFC. It means that that e.g. floats inside are
> seen in full and not overdrawn by neighbors/siblings.
> The main idea and purpose of position:static
> mode is to ensure that content can be seen in full.
> So there is no loss of information for the human as
> on the page here:
> http://www.terrainformatica.com/w3/w3-front-page.png

I'll think on this.  It wouldn't be big change.

~TJ
Received on Friday, 4 June 2010 16:40:52 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:28 GMT