W3C home > Mailing lists > Public > www-style@w3.org > June 2005

Re: Proposal: content-vertical-alignment

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Thu, 9 Jun 2005 11:52:39 -0700
Message-ID: <003001c56d24$694bc230$c302000a@internal.toppro.net>
To: <www-style@w3.org>, "Emrah BASKAYA" <emrahbaskaya@hesido.com>

"....allow any content in a given element to be centered vertically..."

I suppose it means "allow content in any given element to
be centered vertically", right?

If, yes, then  first paragraph in
shall be changed too:

Floats, absolutely positioned elements, inline-blocks, table-cells,
elements with 'overflow' other than 'visible' <<<and
elements with 'content-vertical-alignment' other than 'top' >>> establish
new block formatting contexts.

In fact vertical aligning happens only for containers having height
set explicitly, so above shall be updated to:

Floats, absolutely positioned elements, inline-blocks, table-cells,
elements with 'overflow' other than 'visible' <<<and
elements with 'content-vertical-alignment' other than 'top' and only
those which have height attribute set explicitly >>> establish
new block formatting contexts.



----- Original Message ----- 
From: "Emrah BASKAYA" <emrahbaskaya@hesido.com>
To: <www-style@w3.org>
Sent: Thursday, June 09, 2005 7:32 AM
Subject: Proposal: content-vertical-alignment

> Starting note: Please take your time to read before dismissing.
> Proposal: A new property that will allow any content in a given element to
> be centered vertically:
> content-vertical-align
> Details:
> content-vertical-align: (top | middle | bottom) [default: top]
> Where "top" is the default and all contents are padded after padding-top.
> Where "bottom" will make all contents touch the padding-bottom.
> Where "middle" will make all contents are centered vertically between
> padding-top and padding-bottom.
> Where the content height to be centered will be calculated the same way as
> the current layout module (floating elements will not directly contribute
> to the content height that enlarges the containing element)
> ----------
> Please for those who believe this can be done, and it *can*, please take
> your time to patch missing parts or even make this a fully fledged
> proposal, if you think this as it is is not enough.
> ----------
> Explanation for those who think vertical centering should not be
> implemented because it is 'impossible'; keep in mind:
> 1-) What the browser will do to achieve the 'impossible':
> First of all, browsers will be free to whatever method they employ to
> center the contents vertically. There will be 3 suggestions from me:
>     a) Contents are laid out dynamically as they come.
>           Pros: None
>           Cons: Will create constant motion until the element closing tag
> is reached. Should not be a problem for short content, but this I do not
> advise.
>     b) Contents are not laid out until the element closing tag is reached.
>           Pros: No content would be moving
>           Cons: For long content, the user will have to wait. Not
> recommended.
>     c) Contents are laid out normally after padding-top, and readjusted
> once the element is closed
>           Pros: Users don't have to wait to see content
>           Cons: There is a single centering pop when closing tag is
> reached. Which is no more of a pop when an image whose dimesions are not
> given is loaded and the layout changes vastly, and much more violently
> then the centering pop, as contents move in all directions.
> 2-) The best method is c, I guess. But any could do. Remember, for short
> content, none of the problems mentioned will be a problem. But method c
> gracefully handles even if this is used for really long content.
> 3-) There are so many situations where the layout 'moves' like the loading
> of images with unknown dimensions is one prominent example, last time I
> checked, declaring the image size was not required. The last centering
> motion in method C is much easier on the eye, as the contents move only
> vertically, where as the image size push the text around in all 
> directions.
> 4-) Browsers constantly calculate the content height as they receive data
> anyway, to properly cover them with borders and layout the rest.
> 5-) For browsers that wouldn't support it because what I just point out is
> 'impossible', it is not a problem as "CSS is not and won't be pixel
> perfect". I never knew this notion could be so useful. We shouldn't expect
> to get same results for our CSS for all and design with that in mind
> anyway, isn't this what everybody says? After all, this is 'impossible',
> so we can't blame them if they can't do it, can we? Also, there are many
> unsupported CSS rules and will *always* be, let this be one of them, but
> have it in the specs, who knows, some browsers may choose to take on this
> 'monstrous' task of having to calculate the content length after the
> element is closed.
> Final Words:
> Even tho there is a common belief on the list that I fail to understand
> that it is not possible to have vertical alignment in css, I believe it to
> be plain disgrace to CSS forcing webmasters to use tables instead for the
> job, or going thru hoops and doing several box in box tricks using
> line-height hacks that doesn't work for multiple lines etc. Vertical
> aligning to center is a nice design element tho some may reject, and a
> much needed one. In an ideal world, I know, all pages should look dull(!)
> but there are really nice designs CSS make possible even if we hate to
> admit, let's enhance the CSS's power a little more, so people should find
> little reason to use tables for their layouts instead of CSS.
> -- 
> www.hesido.com
Received on Thursday, 9 June 2005 18:52:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:18 UTC