Re: Proposal: content-vertical-alignment

On Fri, 10 Jun 2005 10:22:54 +0300, Mikko Rantalainen
<mikko.rantalainen@peda.net> wrote:

>
> Emrah BASKAYA wrote:
>> On Thu, 09 Jun 2005 18:25:57 +0300, Mikko Rantalainen
>> <mikko.rantalainen@peda.net> wrote:

> I think that if the box model is claimed to be symmetric, then the  
> behavior should be the same for both vertical and horizontal directions.  
> To me this is logically the same as having multiple non-replaced  
> 'inline-block' elements on a row; the spec already defines such case as  
> following:
>
> http://www.w3.org/TR/CSS21/visudet.html#q12
> "If 'width' is 'auto', the used value is the shrink-to-fit width as for  
> floating elements.
>
> A computed value of 'auto' for 'margin-left' or 'margin-right' becomes a  
> used value of '0'. "
>
> Again, simply replace 'width' with 'height', 'left' with 'top' etc.

Hmm I see your point. So if two block contents meet vertically, their
neighbour margins become a used value of "0", is that true?

>
> After saying that, I don't believe this is a good way to define "margin:  
> auto" for vertical spacing. I think it's a statement that current  
> 'inline-block' layout rules for 'auto' values are not good enough. The  
> whole point of "symmetric" value is to ask the UA to handle both  
> vertical and horizontal sizing identically. All the tweaks we're able to  
> do horizontally will be needed also vertically once the top-to-bottom  
> content keeps increasing in the web.

Giving top to bottom content a fair box model is indeed hard, is there a
switch to change layout order?

>
>
>> One advantage of having to deal with the content position
>> (content-vertical-align) instead of position relative to the parent
>> (margin: auto) is that, we would not *need* to have a parent to adjust  
>> to.
>
> How do you define content position centered to something that isn't the  
> parent? I realize that we need text-vertical-align property if we're  
> claiming to be symmetric, but having properties that *really* access  
> margin values is far from transparent system.

Sorry about mis-wording there, what I mean is, we wouldn't need an *extra*
parent for the parent of the content to adjust to. We center the contents
of an element (which needs no extra wrapping), instead of wrapping content
which is then centered / placed to it parent with margin.

Also, we do not access margin values with content-vertical-align..

To be symmetric (point symmetric of course), content-horizontal-align and
text-vertical-align (how about "justify" vertically, something similar to
Les Brown mentions.) should also be put in the specs.

Also, by definition, as I made clear, this allows us to use even
percentages for the vertical centering, as it treats all content as a
singular block (the block which the UA's are already accustomed to
calculate the height of), this is much easier to understand than using
percentages for margins.



>
> Current system defines "centering" as applying equal margins to all  
> sides of the content. You have to describe new centering features in the  
> same terms.
>
> Also, if I have structure
>
> <div><a/><b/></div>
>
> and rule
>
> div, a, b { content-vertical-align: center; display: block; }
>
> and <div> is higher than than combined height of <a> and <b>, how they  
> will be positioned? If 'content-vertical-align' adjusts "margin"s, how  
> do I define the spacing between <a> and <b>?

The proposal does not play or adjust margins.

First of all, it is clear that any browser, to be able to enlarge a
containing div, should be able to calculate the height of the content. The
proposal brings nothing new in terms of laying out the contents.

This is exactly what this proposal is for.. a and b are laid out like they
would be, vertically one after another. Their total height and vertical
center will be determined, and placed within our <div>, so that a+b's
center will match div's center. Same goes for anything within a, or b. If
the keyword is bottom, the bottom of a+b (laid out normally using ordinary
layout module) will match the bottom of div. (vertical content space in
the div, of course)


>
>> see a reason why two methods should not co-exist. I still believe
>> content-vertical-align is easier to understand and to define, tho.
>
> For the simple case, yes. However, as I reasoned earlier, once you deal  
> with the interactions with margins the positioning could be far from  
> simple. Also, the cascade and inheritance may prove to be hard with this  
> model (just a guess...)
>

Again, there is no interactions with margins in my proposal. My latest
post might clear some things out.



-- 
Emrah BASKAYA
www.hesido.com

Received on Friday, 10 June 2005 14:22:34 UTC