Re: [CSS3] horizontal/vertical-align ?

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Thursday, April 22, 2010 10:54 AM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: <www-style@w3.org>
Subject: Re: [CSS3] horizontal/vertical-align ?

> On Thu, Apr 22, 2010 at 9:39 AM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>> Sorry, but my question still stands -
>> what does vertical-align mean here:
>>
>> span
>> {
>>  display: table-cell;
>>  vertical-align: bottom;
>> }
>> ?
> 
> The element is a table-cell, and thus the table-cell rules apply.
> 
> 
>> If it is a content of the span alignment then how to apply
>> its vertical alignment in line box as here:
>> span
>> {
>>  display: inline-block;
>>  vertical-align: bottom;
>> }
> 
> The element is not a table-cell, and thus the normal text rules apply.
> 
> 
>> This bug in specification prevents vertical-align
>> to be used with any other elements that establish
>> float layout context.  E.g. flexboxes of David Baron
>> or elements under the 'flow' container as in my case.
> 
> I don't understand what you mean here, or what the problem is.

Consider this markup:

<p>One <span>two</span> three</p>

With these styles:

p { line-height:40px; }
span
{
   height:10px;
   border:1px solid;
   display: table-cell;
   vertical-align: bottom;
}

This style should force the span to behave as an inline-table (or table?) 
and the table-cell at the same time. As a table in inline context 
this element should use vertical-align: bottom; to align the block
to bottom of line box. And as a table cell vertical-align: bottom
instructs it to align content to the bottom. 

So either these display:table-*** things are conceptually wrong
or assigning the same name (vertical-align) to completely different
entities was very bad decision at that time.  

I suspect that both of them have design flaws.

Ideally we should be able to define that span as:

span
{
   border: 1px solid;
   display: inline-block; /* or block */
   vertical-align: bottom;
   content-align: middle;
   [content-]flow: vertical; /* or table, horizontal, etc. */
}

> 
> 
>>> The main use-cases for horizontal-align are addressed by flexbox,
>>> which is a layout mode very similar to static layout, but designed
>>> more for the layout of blocks than of text.
>>>
>>
>> flexbox is about free space concept and when element
>> overflows there is no such space at all.
>>
>> Yes, you can say
>>
>> cont { flow:vertical; }
>> cont > elem {  margin-left:*; width:XXXpx; margin-right:0; }
>>
>> to right-align elem box horizontally but this does not address
>> case when 'cont' overflows .
>>
>> Flow/flexes and vertical/horizontal-align makes the layout
>> system complete as these are parts of the same
>> algorithm/functionality.
> 
> Making an element stick to one side or the other is done with the
> box-align property.
> 
> Overflow is indeed not addressed by box-align; it's currently defined
> directly by the direction of the flow.  I have an open question about
> flexbox asking exactly which overflow-direction is best, given a
> particular flow direction (put another way, which direction should be
> before/after, given a particular start/end direction).  I suspect that
> I'll end up adding a property to allow manual control of this,
> precisely so you can, say, have a vertical flexbox on both the left
> and right of a page, and have both of them overflow toward the center
> of the page.
> 
> For normal text flow, the stickiness on blocks can be done by setting
> an appropriate margin to auto.  Overflow is addressed by the direction
> property.
> 

'direction' has no such thing as horizontal-align: center.
'direction' primarily defines text order. Yes it has side effect
of behaving as if horizontal-align: right is defined when 
direction is 'rtl' and 'left' in case of 'ltr' but again 
carving this side-effect in the stone of specification was bad
idea.  There are cases when you need to say:

ul 
{ 
   direction: rtl;
   flow: horizontal;
   horizontal-align: center;
}

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 23 April 2010 02:41:21 UTC