- 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