W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: box-align

From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
Date: Fri, 29 Apr 2011 22:55:42 -0700
Message-ID: <BLU159-ds8F95E310124473B323A09F89D0@phx.gbl>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "Alex Mogilevsky" <alexmog@microsoft.com>, "Brad Kemper" <brad.kemper@gmail.com>, "www-style list" <www-style@w3.org>


-----Original Message----- 
From: Tab Atkins Jr.
Sent: Friday, April 29, 2011 12:55 PM
To: Andrew Fedoniouk
Cc: Alex Mogilevsky ; Brad Kemper ; www-style list
Subject: Re: box-align

>On Fri, Apr 29, 2011 at 9:33 AM, Andrew Fedoniouk
><andrew.fedoniouk@live.com> wrote:
>>> From: Tab Atkins Jr. Sent: Thursday, April 28, 2011 11:04 PM To: Andrew
>>> Fedoniouk Cc: Alex Mogilevsky ; Brad Kemper ; www-style list Subject: 
>>> Re:
>>> box-align
>>> On Thu, Apr 28, 2011 at 9:35 PM, Andrew Fedoniouk
>>> <andrew.fedoniouk@live.com> wrote:
>>>>
>>>
>>> 'vertical-align' is not usable for block-level alignment.  It already
>>> has a well-defined meaning - it aligns inline-level elements within
>>> the linebox.
>>>
>>> Aligning block-level children of an element is something quite
>>> different, and thus should be a separate property.
>>>
>>
>> It would be a true statement if not vertical-align in table-cell elements
>> where it defines exactly
>> what you are going to use for the box-align.
>> Conceptually table-cells replaced in table-row are
>> very close to what is expected from flow:horizontal
>> and vertical alignment there.
>
>The re-use of 'vertical-align' to do content alignment in table cells
>was inarguably a mistake.
>

That is a questionable statement either (see below).

In any case it is already there and no one is going to change this.

So either we will invent bunch of alignments like box-align, grid-align,
cell-align, etc. or we will try to unify all this in vertical-align
(and horizontal-align).

>
>>>> Are you saying that you expect to see something like:
>>>>
>>>> inline-box {
>>>>  vertical-align: baseline;
>>>>  box-align:top right;
>>>> }
>>>>
>>>> ?  What would be the final alignment then?
>>>
>>> Yes, those two work together just fine.  The element in question is
>>> baseline-aligned within its linebox, and then its children are aligned
>>> to the top and right of it.
>>
>> But what will be the baseline of such setup?
>>
>> Consider this markup:
>>
>> <p>Sample <inline-box>
>>          <div>1</div>            <div font-size:200%>2</div>
>> </inline-box> text</p>
>>
>> What will be computed first:
>> a) vertical alignment inside inline-box (and so    inner boxes '1' and 
>> '2'
>> will not have common baseline) and   then an attempt to align these 
>> jagged
>> baseline inside line box, or
>>  b) vertical alignment inside line box using
>>  some yet unknown baseline and then   alignment inside the inline-box. 
>> Where
>>  will be the baseline after that?
>>  In short I would like to see visualization of "those two work together 
>> just
>> fine" using the markup
>> above.
>
>This is fairly simple.  The inline-layout model asks the inline-block
>for its baseline.  The baseline of an inline-block is defined as the
>baseline of its last in-flow linebox.  So then you need to lay out the
>inline-block.  Do so, respecting the alignment, and return the
>position of the last linebox.  Then, align the inline-block within its
>line accordingly.

I am not getting the idea of "last in-flow linebox". Why not the first
for example? Say you have <select size=1> which is under the hood is

<dropdown-select>
  <caption>text</caption><button />
</dropdown-select>

The caption is what really makes sense to align here with the baseline
of contained text. If you will try to use button for that (last in flow) you
will get wrong results.

In other words: in context of inline flex blocks vertical-align:baseline
makes sense when it defines baseline alignment of element inself *and* its
children. Otherwise you will have that artificial first/last problem.

>
>This is precisely the same as what you would do *without* 'box-align'.
> The 'box-align' property doesn't add any complexity whatsoever to the
>overall process - it's just one more step in laying out the
>inline-block before you can return the baseline.
>

Have you guys tried to implement this? I suspect no.

Say you have this:

<p>... text <i-block>A</i-block> <i-block>B</i-block></p>

i-block
{
  box-align: bottom;
  vertical-align: baseline;
}

How exactly you will compute ascent of the i-block?

See: you can compute box-align:bottom only after you
will have height of line box. But to compute line box height
itself you need to know ascent (baseline position) of the
i-block. Chicken-Egg problem in its magnificence.

>
>> From implementation standpoint the only reasonable interpretation of
>> 'vertical-align' is that it defines inner-alignment inside flex block (as 
>> in
>> table-cell).
>
>No, the reasonable interpretation of 'vertical-align' is that it
>doesn't apply to flexbox items, as they're not in a linebox, just like
>how it doesn't apply to display:block elements.  'vertical-align' only
>controls alignment of inline-level elements within a linebox
>(excepting the one mistaken exception of table-cells).
>

Sigh. I understand that it is hard to get all this abstractedly.
I'll better wait until you start implementing all this.

I've found that to solve that chicken-egg problem you need
to follow these two principles:
1) vertical-align defines as outer as inner alignment in inline
   flex blocks.
2) Inline blocks having vertical flexes are not participating
   in ascent (baseline) computations. Vertical flexes are computed
   after line box gets its height and so baseline position.
   (Your box-align as part of flex computation is here too).

-- 
Andrew Fedoniouk

http://terrainformatica.com 
Received on Saturday, 30 April 2011 05:56:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:39 GMT