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

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Thursday, June 03, 2010 9:16 AM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "Brad Kemper" <brad.kemper@gmail.com>; "Zack Weinberg" 
<zweinberg@mozilla.com>; <www-style@w3.org>
Subject: Re: [css3-flex] calc(flex) and concept of free space.

> On Wed, Jun 2, 2010 at 9:03 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>>>> There are terms "preflex length" and "relevant preflex length"
>>>> but they were not defined anywhere.
>>>
>>> Dude, the definitions are right there at the bottoms of section 6.1 and
>>> 6.2..
>>>
>>
>> Just for the record: that sentence of mine is using Past Tense.
>> At the moment of initial writing it used to be no definition
>> of "preflex length".
>
> No, those definitions have been there since I first put this draft up
> on the list two weeks ago.
>

Let's assume that I've missed it at that moment. Terribly sorry.

>>
>> 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).


>>
>> 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".

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 ?



>> 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...

>
>> 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"?

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)

For the record: HTML tables use max-intrinsic width as a
preferred width of columns. So two columns with
undefined width have final widths proportional to
the length of content in them.

>
> 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.

>
>
>>>> 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.

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



>
>
>> E.g. in
>>  display:table-cell element (and in Gecko flex model, AFAIU):
>>  <computed min width> is max (width, min-width, min-intrinsic)
>> in display:block elements
>>   <computed min width> is max (width, min-width)
>
> No, in Gecko's flex model (from the current draft, maybe not from XUL)
> the <computed min width> is max(width, min-width) and the <computed
> preferred width> is max(width, min-content).

That does not match example above so
we need to ask David what is more correct here, their implementation or
or his spec.

>> I am also using max (width, min-width, min-intrinsic)
>> in flex blocks.
>>
>> Is it in principle possible in your model to define something
>> like
>>  width:calc(500px + 1fx) overflow:never?
>> or in other words:
>>  width:calc(500px + 1fx) min-width:min-intrinsic
>> ? So that element will never overflow.
>
> Yes, precisely the way you did it in the second example.  If you don't
> want a box to shrink below a certain width, you use min-width - that's
> the whole reason that property exists.
>

That min-width: fit-content I guess?
Do you know by any chance where it was discussed so I can read by myself?

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Friday, 4 June 2010 04:35:51 UTC