- From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
- Date: Thu, 28 Apr 2011 21:35:18 -0700
- To: "Alex Mogilevsky" <alexmog@microsoft.com>, "Andrew Fedoniouk" <news@terrainformatica.com>, "Brad Kemper" <brad.kemper@gmail.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "www-style list" <www-style@w3.org>
"if it's current definition were not so complicated already"
and what exactly is so complex there?
"If there is a new kind of alignment, it should be a new property."
Umm... Alignment is alignment. I am not sure I understand you here...
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?
And yet: I suspect that TTB writing systems require
'horizontal-align' to have most of 'vertical-align' values
for symmetry.
"Currently <center> cannot be defined using CSS."
As also <table align="center"> from HTML 4
--
Andrew Fedoniouk
http://terrainformatica.com
-----Original Message-----
From: Alex Mogilevsky
Sent: Thursday, April 28, 2011 6:41 AM
To: Andrew Fedoniouk ; Brad Kemper
Cc: Tab Atkins Jr. ; www-style list
Subject: RE: box-align
It would make sense to reuse vertical-align property if it's current
definition were not so complicated already. If there is a new kind of
alignment, it should be a new property.
Extending 'box-align' to cover the behavior of <center> tag is an
interesting proposal. Currently <center> cannot be defined using CSS.
Decisions that led to it were done before my time, but I am sure it is on
purpose. Perhaps older CSSWG members could share why <center> is not
possible in CSS, and if extending 'box-align' in that direction is a good
idea?
As far as implementation goes, it should be straightforward to do, because
all browsers do implement <center>.
-----Original Message-----
From: Andrew Fedoniouk [mailto:andrew.fedoniouk@live.com]
Sent: Wednesday, April 27, 2011 7:08 AM
To: Brad Kemper; Alex Mogilevsky
Cc: Tab Atkins Jr.; www-style list
Subject: Re: box-align
"Perhaps it could take two values, one for horizontal and one for vertical"
It is a must in my opinion:
It has to be two alignment properties: vertical-align and horizontal-align.
Current vertical-align property can be used in flex contexts as it is.
New property for that is not required.
For the illustration consider following setup:
<p>Some text:
<widget><label>...</label><button /></widget>.</p>
The widget here is declared as
widget {
display:inline-block;
flow:horizontal;
vertical-align:baseline; }
This means the widget will be baseline aligned inside line box with its
outer text and its children will be aligned to the same baseline. So we
will see something close to this:
Some text: [[label][b]].
When flex block is placed inside block container contexts (so it is
display:block & friends) then the meaning of 'vertical-align'
is exactly the same as in table cells. Nothing new here at all.
So vertical-align property defines outer-alignment of block itself and
inner-alignment - alignment of its children inside it.
In display:block topologies (like display:table-cell) the vertical-align
defines inner-alignment only.
Inner-alignment of flex block is using following mapping of
'vertical-align' values:
baseline | sub | super -> content 'baseline' aligned
top | text-top - content 'top' aligned
middle - content 'middle' aligned
bottom | text-bottom - bottom alignment.
As order of vertical layout calculations is this:
1. Do any vertical flex computations and if there is a free space
left then
2. Do vertical alignment according to 'vertical-align' using free space
left from previous step.
then flex units can be used to override vertical-align values for particular
children.
( In the widget above <button> may have padding:1* 0; defined so it will
span whole height of the widget )
'horizontal-align' property accepts values 'left' | 'center' | 'right'
and again is being used as last step of horizontal layout calculations.
Both vertical-align and horizontal-align define also rendering behavior of
overflowed element.
Imagine that flex block is defined with overflow:hidden; and it has content
that overflows. Let it be flow:vertical for illustration.
In this case for horizontal-align:right we will see rightmost sides of child
elements. Left sides of children will be cut off.
The same model is for vertical-align. With vertical-align:bottom last child
will be always visible and first one will be hidden if it does not fit. The
same is about overflow:scroll; - alignment defines scroll position invariant
when dimensions of flex block are changing.
If will decide to use separate property for content block alignment (like
'box-align' for example) then we should have clear model of interaction
between that 'box-align' and 'vertical-align'. Especially in line box
(display:inline-block; flow:horizontal) contexts.
--
Andrew Fedoniouk
http://terrainformatica.com
-----Original Message-----
From: Brad Kemper
Sent: Tuesday, April 26, 2011 7:28 AM
To: Alex Mogilevsky
Cc: Tab Atkins Jr. ; www-style list
Subject: box-align
On Apr 25, 2011, at 11:06 PM, Alex Mogilevsky wrote:
> So the meaning of box-align is to do what table cells do with 'vertical
> align', with same values, right? But it is still just about alignment in
> block direction?
Perhaps it could take two values, one for horizontal and one for vertical
(if only one value is given, then it sets both to the same thing). The
horizontal value would be like the <center> tag, centering children of the
block.
Received on Friday, 29 April 2011 04:35:50 UTC