Re: Publishing the flexible box model

L. David Baron wrote:
> On Wednesday 2008-06-04 20:09 -0700, Andrew Fedoniouk wrote:
>> L. David Baron wrote:
>>> On Wednesday 2008-06-04 17:50 -0700, Andrew Fedoniouk wrote:
>>>> Consider following markup:
>>>>
>>>> <body>
>>>>  <div>On the top</div>
>>>>  <div>On the bottom</div>
>>>> </body>
>>>>
>>>> and we would like to "stick" second div to the bottom and first one 
>>>> to  the top of the view. How would you
>>>> accomplish that with XUL flexes? Probably I have missed something but 
>>>>  that is impossible with XUL flexes.
>>> <body style="display:box; box-orient:vertical">
>>>   <div>On the top</div>
>>>   <div style="box-flex: 1"></div> <!-- maybe needs 'display: box' ? -->
>>>   <div>On the bottom</div>
>>> </body>
>> David, I think you already know why this is bad.
>> div in the middle is not a solution if we speak about CSS.
> 
> I think you're stretching the example, though.  The normal reason to
> want one thing at the top edge and another at the bottom edge is
> because you have something else that you want to fill the space
> between them.

If you have Thunderbird application nearby :) then take a look
on the Search field on toolbar. That input element has margin-left:1*;
(or margin-right:1*). There are many other cases in UI when you need
to do such kind of alignments. In both directions.

That, when implemented, will cover many cases where floats
are heavily misused now.

> 
> That said, there are always going to be presentations that authors
> want that require boxes that don't have a corresponding element in
> the markup.  I agree that we need better mechanisms for generated
> content.
> 
>>>> Flexibility is really a length unit rather than some property.
>>> No, since some layout models (traditional document layout) use one
>>> dimension as input and the other as output; you can only flex in a
>>> dimension that is input to the algorithm.  In the existing CSS
>>> model, in many cases, there is no sensible height that is input to
>>> the algorithm (or, depending on how you look at it, multiple heights
>>> that might be of interest).
>>>
>> I am not sure I understand this:
>> "you can *only* flex in a dimension that is input to the algorithm"
>>
>> This
>>   <body><table width=100% height=100%></table></body>
>> works perfectly well in Gecko as in other engines.
> 
> And tables are a separate layout model from block layout, and can
> (optionally) use the viewport height, or the height of the closest
> containing block with a fixed height, or maybe something else
> depending on quirks mode, as input.
> 
> You can always add more complications to an existing model if you
> want.  So I suppose that point wasn't particularly relevant.

So you say that eight new attributes will create less complications
than one attribute and one length unit?

Sorry, but 1) this is not so and 2) flex length unit solves 
significantly more cases than such pretty artificial DOM-flex-element.

The only complication/logical conflict I've met during 3 years of use
of these flex units is the floats. Floats as an entity is the main 
obstacle for any vertical or horizontal alignments. That flex-box
you propose included.

The best idea so far is this:
Block element that has parent with defined @flow establishes
container box for floats.

Other than floats there are *no other* logical conflicts with
flex units and the rest of CSS. At all.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Thursday, 5 June 2008 06:40:37 UTC