Re: Publishing the flexible box model

Robert O'Callahan wrote:

> > On Tue, Jun 10, 2008 at 7:03 PM, Andrew Fedoniouk 
> > <news@terrainformatica.com <mailto:news@terrainformatica.com>> wrote:
> > 
> >     Robert O'Callahan wrote:
> > 
> >         What does that have to do with absolute positioning and
> >         http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width ?
> > 
> > 
> >     There is nothing special with this in respect of flexes. Or I do not
> >     understand your question.
> > 
> >     You calculate positions of elements including flexes.
> >     After that you will have "would-be-position"s of absolute
> >     elements and you replace them accordingly to their left...bottom
> >     attributes.
> > 
> >     Is this what you were asking?
> > 
> > 
> > No. The rules in that section describe how to size and position an 
> > absolutely positioned element based on the values of its margin, 
> > padding, border and content size properties. Those rules do not consider 
> > flexunit values. You need to explain how the rules are extended to 
> > handle flexunit values. Are they just treated as auto?
> > 
>   

Ah, that one...

position:absolute element is taken out of normal flow of
its parent. Thus such an element is excluded from
distribution of free space of its parent.

For position:absolute elements flex values are treated
as having 'auto' value.

But as I said before it is a desire expressed by practical
use to allow left/top/right/bottom flexes. So to have flexible
absolute positioning:
{
   position:absolute;
   left,top,right,bottom: 1*;
}


> > 
> > 
> >         A few more questions about flex-units:
> > 
> >         Does 'flow' apply to inline elements? If so, what does
> >         'flow:vertical' do on an inline element?
> > 
> > 
> >     As I said flow is applicable only to elements that establish boxes -
> >     so to create bounds for flex length distribution. Inlines are
> >     clearly not such blocks.
> > 
> > 
> > That's confusing. In CSS all rendered elements create boxes. Your 
> > explanation that 'flow' only applies to elements that are block-inside 
> > makes more sense.
>   

Let's assume for brevity that flexes are not applicable to
display:inline elements at all.

Yes, technically speaking there are attributes in didsplay:inline that
could have flexes but they have almost no practical value.

> > 
> > 
> > 
> >         How do flexunits work on inline elements that break across
> >         multiple lines? e.g
> >         <span style="font-size:50px;">Foo</span> <span
> >         style="padding-top:1*">A<br>B<br>C</span> <span
> >         style="font-size:80px;">qux</span>
> >         Which line box(es) are used to determine the padding? Does each
> >         line of the <span> actually get a different padding?
> > 
> > 
> >     Flex units are defined only for blocks and block-alike elements.
> >     display: block | inline-block | table | table-cell | etc.
> > 
> > 
> > Hang on, you just said that 'flow' only applies to elements with block 
> > layout inside, so why does it make sense to apply flex units to table-cell?
>   

I'd better provide an example:

<td style="flow:horizontal; direction:ltr">
   <div>left</div>
   <div>right</div>
</td>


> > 
> > 
> >     inline elements have no concept of dimension. In the same way
> >     as width:100px does not work for inline elements in the same
> >     way flex length units do not work there either.
> > 
> > 
> > But padding does work for inline elements, so one might expect flexunits 
> > padding to work on them too. In fact here
> > http://lists.w3.org/Archives/Public/www-style/2008Jun/0043.html
> > I asked a question that assumed inline elements could have flex padding 
> > and you agreed.
>   

Sorry I misunderstood you in previous message. inline-blocks can have
flexes, in inline elements all flexes will become 'auto's.

Technically for display:inline elements you could have
something like padding:1*; but I do not see any value of that.

> >  
> > 
> > 
> >         How do flexunits interact with absolute positioning and auto
> >         top/left? Is the hypothetical position for the content computed
> >         taking flexunit margins/padding on the content into account?
> > 
> > 
> >     Yes.
> > 
> > 
> > I mean, given
> > <div style="flow:vertical; position:relative; height:200px; overflow:auto;">
> > Hello
> > <div style="margin:1*; position:absolute;"></div>
> > Kitty
> > </div>
> > The position of the inner div is computed "assuming it was in the flow" 
> > according to CSS2.1. Does that mean you have to compute the space that 
> > would be assigned to the flex margin if the inner div was in-flow?
>   

No. position:absolute element does not affect normal flow of its
siblings. flex units on such elements are evaluated to 'auto' values.


> > 
> > 
> >     Here is a screenshot if you wish:
> >     http://terrainformatica.com/htmlayout/images/css-menus.png
> > 
> > Nice example, but it doesn't illustrate my question since the abs-pos 
> > element doesn't have flexunits on it.
> > 
> > By the way, you probably should have a close look at your decision to 
> > make block descendants of an element with 'flow' all block formatting 
> > contexts. That means that margin collapsing never happens across the 
> > boundaries of these blocks, so the discussion we had earlier about 
> > margin-collapsing and flex-units is moot. That's probably a good step 
> > but apparently that's not what you've implemented. You probably should 
> > also work out more precisely what you mean by that restriction to make 
> > it clear exactly which blocks are affected and how.
>   

I did not say that "block descendants of an element with 'flow' *all*
block formatting contexts."

Only if float appear somewhere inside block in flex context that
block is said to be block formatting contexts for that float element.


> > 
> > I hope I've convinced you by now that there is a lot that a flexunits 
> > spec needs to say, and what it should say is not all obvious.
> > 
>   

I do not say that changing spec will be trivial. Changes need to be done 
in any case. I am saying that magnitude of changes will be the same
as for flexbox as for flex units. But it is better to add such mechanism
once and in the version that is known to be more flexible/universal
upfront.

Concept of flexes is natural for human and is well known and obvious for 
people who make web design professionally. Tables are using flex concept
already. Badly defined/specified but it is there. Flex units will help
to formalize this too. At least for things like display:table-cell 
flexes will allow to get to HTML tables as close as possible in CSS.

-- Andrew Fedoniouk. http://terrainformatica.com

Received on Tuesday, 10 June 2008 20:00:09 UTC