Vertical alignment of text within a DIV

[Spartanicus]

Re: Vertical alignment of text within a DIV

"Wayne Poe" <louis@h4h.comw rote:

>It is common for people to take IE's rendering as correct, not least
>because it often does what people expect. Where Moz and IE differ,
>IE's rendering is almost certainly wrong.

>
>This is not always true. It depends a lot on which mode is being engaged
>in whichever browser.

All bets are off if you are referring to quirks mode, but it most
certainly is true for standards compliant mode which I assumed you
referred to when you wrote:

>>Actually, with strict on, I've witnessed many anomalies on the
>>Moz/FF/NS side of things, just as much as I've seen on the IE side.

We will happily prove you wrong, just post examples. (note that I for
one only review URLs).

>It may well turn out to be impossible to retain the aspects that make
>tables such a popular method to create layouts whilst avoiding the
>nasty consequences.

>
>I'm sorry, but I've all too fequently how bad <table>s are for layout
>purposesare, but hardly ever do I see a real ellaboration on that. Tell
>me, what is truely so bad abotu using <table>s for layout?

1) Reflows (a) when embedded content loads in table-layout:auto mode.
2) Do not contain their content properly (b) in table-layout:fixed mode.
3) Grid remains rigid regardless of the viewport width (c).
4) The content order cannot be changed independently from the position
on screen.

(a) Reflows: screen content jumping around like a mexican jumping bean
because the rendering of the layout grid depends on it's content.
(b) Containing contents, there is no acceptable overflow behaviour:
1) In document scroll bars (usability nightmare).
2) Part of the content is clipped (content partially disappearing is
unacceptable).
3) Part of the content overflows into the adjoining space (thereby often
obscuring other content).

(c) The CSS2 "handheld" media property was ill conceived, it made
unwarranted assumptions about the viewport width on mobile devices, and
fails to cater for a-typical viewport widths on non mobile devices.

Sadly most of the properties that make table layouts so popular amongst
authors are directly responsible for the problems they cause for
clients. The user's interests ought to trump the author's desire for
simplicity.

--
Spartanicus

[Wayne Poe]

Re: Vertical alignment of text within a DIV

Spartanicus wrote:

"Wayne Poe" <louis@h4h.comw rote:

[...]

>>It may well turn out to be impossible to retain the aspects that
>>make tables such a popular method to create layouts whilst avoiding
>>the nasty consequences.

>>
>I'm sorry, but I've all too fequently how bad <table>s are for layout
>purposesare, but hardly ever do I see a real ellaboration on that.
>Tell me, what is truely so bad abotu using <table>s for layout?

>
1) Reflows (a) when embedded content loads in table-layout:auto mode.

That a characteristic of how rendering in general (of the browser) takes
place, not something specific to <tablelayouts .

2) Do not contain their content properly (b) in table-layout:fixed

Um you got it backwards, it's <divs that can't seem to stay with it's
borders in many cases when you expect it should. <tds will not
normally allow content to spill out of their confines.

mode. 3) Grid remains rigid regardless of the viewport width (c).

This is not disadvantage of <table>, as all you have to do is scroll,
and this can sometimes be desired, depending on your target audience.
Actually one could argue the it SHOULD ork that way.

If you have a have a side column and flexible width main column, why
woul you want anything other than the side column remaining on the,
well, SIDE? I would arue thats the whole point of using a <tablefor
this sort of laytout in the first place. Many people just don't want the
behavior of <divs sliding under seach other.

4) The content order cannot be changed independently from the position
on screen.
>
(a) Reflows: screen content jumping around like a mexican jumping bean
because the rendering of the layout grid depends on it's content.

Again, this is NOT specific to a <table>, but <divs can do the same
with the width is unspecified and you have a whole lot of content coming
in. Thats a charasteristic of the rendering engine.

(b) Containing contents, there is no acceptable overflow behaviour:

How so? Is this not how the auth sets it (<td style="overflow : ..."and
as I said, the default behavior may be desired, which keeps the contents
from spilling out of it's confines and pushes the sides of the
containing cel las need to fit the content, something horribly difficult
with CSS/div layouts.

1) In document scroll bars (usability nightmare).

What on earch are you talking about? How does this have anything
specifically to do with tables? Default behavior of tables is no scroll
bars i nthe cells. If you had been using HTML for sometiem you would
this. One can also change the default behavoir of a cell using an
overflow style.

2) Part of the content is clipped (content partially disappearing is
unacceptable).

In <tabless? This is just plain false. With divs, perhaps, I've seen
that happen with overflow: hide, but this applies to must any block
elements.

Going be a table's default behavior, I can't think of any time such
clipping as you describe occurs at all.

3) Part of the content overflows into the adjoining space (thereby
often obscuring other content).

Not in <tables. THAT is precisely what can happen with pure CSS/div
layouts (albiet, the design of the page itself might be flawed if this
is happening. It has absolutely nothing to do with <tablelayouts . That
is purely a stylesheet / CSS layout issue.

(c) The CSS2 "handheld" media property was ill conceived, it made
unwarranted assumptions about the viewport width on mobile devices,

True, which is why it seem to hardly be used ever.

and fails to cater for a-typical viewport widths on non mobile
devices.

And why should it? Thats more the job of the page author than anyone
else to ensure the pages they write appear as expected (or at least
acceptably) on the target medias.

Sadly most of the properties that make table layouts so popular
amongst authors are directly responsible for the problems they cause
for clients.

What problems are that? I've never seen <tablebased layouts fail in
the same way div/CSS layouts do when care isn't taken.

The user's interests ought to trump the author's desire
for simplicity.

True, but you still need to create a design. It depends on who you are
developing for, their needs. The target audience. There are many cases
in my work where the customer wanted the simple <tablelayout.

[Spartanicus]

Re: Vertical alignment of text within a DIV

"Wayne Poe" <louis@h4h.comw rote:

>>I'm sorry, but I've all too fequently how bad <table>s are for layout
>>purposesare , but hardly ever do I see a real ellaboration on that.
>>Tell me, what is truely so bad abotu using <table>s for layout?

>>
>1) Reflows (a) when embedded content loads in table-layout:auto mode.

>
>That a characteristic of how rendering in general (of the browser) takes
>place, not something specific to <tablelayouts .

Content in the flow is rendered according to an inline or block
mechanism, content below a line or block box does not affect content
above it. Not so with a table layout, there content below a row can and
often will cause the entire table to reflow.

>2) Do not contain their content properly (b) in table-layout:fixed

>
>Um you got it backwards, it's <divs that can't seem to stay with it's
>borders in many cases when you expect it should. <tds will not
>normally allow content to spill out of their confines.

http://www.w3.org/TR/CSS21/tables.html#width-layout

I presented two cases since different arguments apply to each mode.

>mode. 3) Grid remains rigid regardless of the viewport width (c).

>
>This is not disadvantage of <table>, as all you have to do is scroll,
>and this can sometimes be desired, depending on your target audience.
>Actually one could argue the it SHOULD ork that way.

I referred to the fact that working within the possibilities of CSS2,
table cells stay in the same grid pattern regardless of viewport width
(with the previously noted exception). This is a serious problem when
the size of the output medium varies greatly as it does with the range
of web clients in use today.

>4) The content order cannot be changed independently from the position
>on screen.
>>
>(a) Reflows: screen content jumping around like a mexican jumping bean
>because the rendering of the layout grid depends on it's content.

>
>Again, this is NOT specific to a <table>, but <divs can do the same
>with the width is unspecified and you have a whole lot of content coming
>in. Thats a charasteristic of the rendering engine.
>

>(b) Containing contents, there is no acceptable overflow behaviour:

>
>How so? Is this not how the auth sets it (<td style="overflow : ..."and
>as I said, the default behavior may be desired, which keeps the contents
>from spilling out of it's confines and pushes the sides of the
>containing cel las need to fit the content,

Which is a major problem, one that you appear to be oblivious of, or are
refusing to see.

>something horribly difficult with CSS/div layouts.

Again this is perfectly possible with CSS2, just not supported by IE.

>1) In document scroll bars (usability nightmare).

>
>What on earch are you talking about? How does this have anything
>specifically to do with tables?

Tables can be rendered in two modes. Again: I presented two cases since
different arguments apply to both. I suggest that you read what I wrote
more attentively, currently most seems to pass you by.

>(c) The CSS2 "handheld" media property was ill conceived, it made
>unwarranted assumptions about the viewport width on mobile devices,

>
>True, which is why it seem to hardly be used ever.
>

>and fails to cater for a-typical viewport widths on non mobile
>devices.

>
>And why should it?

Because the range of viewport widths with for example desktop situations
is extensive.

>Sadly most of the properties that make table layouts so popular
>amongst authors are directly responsible for the problems they cause
>for clients.

>
>What problems are that?

That is what I've been explaining, I can't help if you ignore what I
write.

>I've never seen <tablebased layouts fail in
>the same way div/CSS layouts do when care isn't taken.

I can't quite parse that, when care isn't taken with what, table layouts
or "CSS layouts"?

Table layouts have specific failures.

A CSS layout coded by a skilled author is not particularly prone to
failure, there are however a lot of poorly authored "CSS layouts".

>The user's interests ought to trump the author's desire
>for simplicity.

>
>True, but you still need to create a design. It depends on who you are
>developing for, their needs. The target audience. There are many cases
>in my work where the customer wanted the simple <tablelayout.

Creating problems for the user is not in the interest of anyone.

--
Spartanicus

[Jim Moe]

Re: Vertical alignment of text within a DIV

Wayne Poe wrote:

>>

>>>Equal "column" height is possible with CSS2 methods, but IE doesn't
>>>support that part of CSS2.
>>>
>>Well, yes and no. Correct me if I'm wrong, but when IE6 first came
>>out, wasn't CSS2 not yet finalized?

>>
>CSS 2.0 achieved Rec status in 1998, IE6 stems from 2000 IIRC.

>
I stand corrected, though I would put forth that it wasn't really
feasable for widespread use (in terms of anything beyond forrmatting -
ie layouts) for a sometime well after 2000, as the majority of the web
in 2000 seem to be using the "old fashioned" <tablewrapper approach,
and somewhat popularity of NN 4.x didn't exactly help in the area of CS
layouts at the time, imho.
>

IE6 has been almost completely static in terms of features and standards
compliance since 2000 when it was released. Given the thousands of repairs
for security fixes I would have thought they would slip in a few useful
fixes for rendering. Hah!

--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)