content-vertical-align and What is CSS aiming? (was Re: Vertical Alignment)

On Mon, 06 Jun 2005 23:20:24 +0300, David Woolley  
<david@djwhome.demon.co.uk> wrote:

>
>> I'm wondering, why the "vertical-align" property is restricted to
> ** table and inline elements. Actually in about 60% of the cases, in  
> which
>
> The basic problem in block contexts is that it requires a look ahead,
> or that the display keep moving as more data arrives, or a sudden
> jump when the element is closed.  It's also not too clear what it means
> in a paginated context.
>

You mean there can be no possible way of vertical-aligning to center of  
the block elements, and because of this?? I don't think the sudden jump or  
the content moving would cause epileptic seizures. e.g. To prevent moving,  
the browsers could first rely on padding-top to place content is fully  
loaded and then vertically align, or decide to wait until content arrives,  
which, in MOST cases would not be more than a few parapraphs, then those  
who use content-vertical-alignment to middle for 5 pages long content  
should be condemned indeed and severely punished by the browser with the  
jump at the end which would give them quite a headache. But those "few"  
who'd like to put a banner image and a few words next to it would be  
rewarded by this possibility, as they wouldn't have to use strange  
workarounds. I don't mean to harm the current vertical-align property, it  
is good as it is. There could be an extra content-valign: (middle | top |  
bottom | auto) which leaves no space for misunderstandings. If anyone  
manages to misunderstand this, please come up with a better name.

And now, what is CSS aiming?:
We shall never preach people to use CSS for layout, because it lacks some  
basic layout commands. And we shall never preach them do flexible layouts  
that fill entire screens using percentages as the "supreme" box model  
system doesn't put margins and borders into the width, as if it was  
possible to actually do sth like width: (75% - 20px). If this could be  
done, I wouldn't feel bitter at all about the current box-model, but as  
this and many other simple things aren't made possible, CSS doesn't  
deliver the abstraction it promises. (and I don't take "box in box" and  
"box in box in another box next to another" as an answer for this example)  
Hopefully, with css3, this will change, but the current box model has done  
enough setbacks to the advance of CSS, as CSS3 can crowd the market only  
after so many years.

People are talking real passionately about selectors. The discussion on  
them here are on par with any academic discussion, as there are many  
bright people here that put nice ideas to the discussion. I agree, really  
nice things can be done with them, and they are extremely well thought  
about. But here is the catch:
Not many people will care to use them, esp. the complex ones. Why? I'd  
guess it would be simply because, they would mostly serve for sites with  
lots of content, probably generated dynamically. And when you have a big  
page generated dynamically, you can add classes and id's with your content  
generator (ASP, PHP, etc) . When you have a small page, you'd then simply  
manually add classes. Sure, we DO need selectors badly, but we don't need  
complex ones at all. Let's not waste one more hour on them.

I am appalled at the disinterest to give CSS3 the true seperate  
style/layout from content abilities while giving so many man-hours to the  
selectors and such. I once did a suggestion on rearranging element order  
proposal, tho not on par with other educated proposals here, it helped do  
just that. Instead of talking hours on how to enhance the selectors, some  
of you could devote time to propose a much better proposal then mine. I am  
talking about a "how it could be done" attitude, and not "why it can't be  
done" attitude is what this list needs.

Yours,
-- 
Emrah BASKAYA
www.hesido.com

Received on Monday, 6 June 2005 21:29:54 UTC