Re: [CSS3] horizontal/vertical-align ?

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

> On Thu, Apr 22, 2010 at 7:40 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>> 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.
>
> No, it acts like a table-cell only.  It has an inline-table anonymous
> wrapping box (along with at least a table-row wrapper, and maybe a
> table-row-group?  I forget).

That's the thing with that auto table generation - if you have
declared something as display: table-cell you have no control
for what it will generate: table or inline-table.  Too bad.

Splitting display into display-model/role may help here but
not too much as the main purpose to use table-cell in this circumstances
is of its unique interpretation of width:auto;

Take a look on this page:
http://terrainformatica.com/forums/topic.php?id=1302
Source code blocks there are declared as display:table-cell and
so they behave as if they have width:max-intrinsic; defined.

Such kind of hacks based on side-effects are extremely bad.
It should be a way to define such things explicitly.

That display:table-*** stuff is really not needed if you have
flexes and 'flow' (that includes "template").  You can
define layout reliably and predictable without generation of
those mysterious row/table boxes.

>
> Thus, since it's a table-cell, vertical-align works as per tables.
>
> (This is a potential use-case for either ::inside or ::outside, btw -
> you could then use vertical-align both to align the box in the linebox
> and to align the contents of the table-cell.)

::inside and ::outside is a sort of shadow DOM generator for CSS,
is this the idea?

>
> I agree that reusing vertical-align to align the contents of a table
> box was a design mistake.  But it's not something we can change at
> this point, so shrug.  It's not contradictory in any way, though, just
> occasionally inconvenient.

It is inconvenient already. David's Flexbox establishes float containing
context ("flow root"?) in the same way as table cells and so such
elements can interpret vertical/horizontal-align too.

And there are very useful case when you will want to declare
things like:

span
{
   display: inline-block;
   width: max-intrinsic;
   flow: "a b"
            "c c";
   vertical-align: center;
}

>
>
>> '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;
>> }
>
> I agree, and Flexbox has some ability to do that now.  I expect that
> I'll add a fuller ability to control this in my revision.

Question that bothers me quite some time:
why you think that Flexbox module with its eight or so properties is
better or easier to implement than single 'flow' property
and flex unit? If you add there fact that 'flow' covers
essential part of Template proposal with its own properties and
at least two additional length units then you will get

  1prop/1unit  against ~8props/2units

Why there is such an opinion here that 8props/2units will
require significantly less effort to implement or for
some other reasons better, understandable, etc.?
Have no idea to be short.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Saturday, 24 April 2010 06:11:50 UTC