Replacing small layout table by CSS floats not working properly

[Daniel Kabs]

Hi there,

for a long time I've been using tables to layout elements on a web page.

Example: Say we have a 2x2 table and I'd like to put text (left aligned)
and buttons (right aligned) in the top right table cell. These elements
should stay on one line and the table should keep a minimum width in
order to prevent wrapping.

-------------------------------------------------
| text | text text Button Button Button |
+------+----------------------------------------+
| text | text |
-------------------------------------------------

A simple and fast solution is to put the elements inside a nested layout
table and adding the NOWRAP attribute to the TD elements.

With the improved CSS support in current browsers, dumping layout tables
in favour of CSS is in order, I guess. So I started with this small
problem and tried to replace the nested layout table using CSS
controlled HTML elements instead. See my solution here:

http://www.mobotixserver.de/~daniel/..._float_en.html

I set the Buttons to "float:righ t" and the table cell to
"white-space:nowrap;". Everything looks ok until the browser window is
resized. The table shrinks as the browser window shrinks. Firefox moves
the Buttons over the text, IE wraps everything.

I can not believe that CSS fails on simple problems like this. How can I
improve my imperfect CSS approach? Thanks for any help.

Cheers
Daniel

[Andy Dingley]

Daniel Kabs wrote:

I can not believe that CSS fails on simple problems like this.

It doesn't fail, it just takes a different approach to being asked to
do the impossible. If you make a design that needs a certain minimum
width to function, then how can it be expected to render in a smaller
space? _Something_ has to give.

The <tableversion fails because it preserves the table minimum width
at the cost of overflowing the page -- which is still a failure from a
usability viewpoint. It's no better or worse than CSS, it's just
different. If you want this sort of behaviour, set min-width on the
container element.

IE is of course just broken.

[Daniel Kabs]

Hello Andy,

thanks for your comment. Your point of view is interesting. I never saw
the problem from that perspective.

You are right, something has to give. If the table does not fit on the
browser page, I like to hint the browser what to do. In this case, I'd
like the browser to display the Text and Button elements on one line
without wrapping.

So what happens if the text length increases. Say, because the text has
been translated to french and now needs more space?

Firefox obviously runs the text underneath the buttons, so the buttons
cover the text. I guess, this is because floating elements are taken out
of the usual HTML flow.

There are two solutions. Either wrap or increase the size of the
container element (even beyond the browser window width, so scrollbars
appear). Do you know how to do the latter?

If you want this sort of behaviour, set min-width on the
container element.

The container element in this case is the top right table cell.
I don't know its absolute pixel width as it depends on the text and the
number of buttons. In the layout table solution, I just add the
attribute width="100%" but I guess, setting min-width of a table cell to
100% makes no sense.

Although I do not like the idea of setting absolute sizes, I tried to
set the table to a fixed width of 600px using width and min-width but
this does not change anything. The table still shrinks, text and buttons
wrap.

Cheers
Daniel

[Wayne Poe]

Andy Dingley wrote:

Daniel Kabs wrote:

I can not believe that CSS fails on simple problems like this.

It doesn't fail, it just takes a different approach to being asked to
do the impossible. If you make a design that needs a certain minimum
width to function, then how can it be expected to render in a smaller
space? _Something_ has to give.

The <tableversion fails because it preserves the table minimum width
at the cost of overflowing the page -- which is still a failure from a
usability viewpoint. It's no better or worse than CSS, it's just
different. If you want this sort of behaviour, set min-width on the
container element.

IE is of course just broken.

How bigoted this last statement is. Do you know who many problems I've
run into on the NN/Moz/FF side of things? No browser is perfect, and no
browser renders 100% currect, so implying that IE is broken and others
are not to some degree is just unnecessary bias we don't need here.

The fact is, IE sometimes displays things correctly where FF and NN
fail, and vice versa. It's a two, not one, way street.

[Chris F.A. Johnson]

On 2006-08-30, Wayne Poe wrote:

Andy Dingley wrote:

>Daniel Kabs wrote:

I can not believe that CSS fails on simple problems like this.

It doesn't fail, it just takes a different approach to being asked to
do the impossible. If you make a design that needs a certain minimum
width to function, then how can it be expected to render in a smaller
space? _Something_ has to give.

The <tableversion fails because it preserves the table minimum width
at the cost of overflowing the page -- which is still a failure from a
usability viewpoint. It's no better or worse than CSS, it's just
different. If you want this sort of behaviour, set min-width on the
container element.

>IE is of course just broken.

How bigoted this last statement is. Do you know who many problems I've
run into on the NN/Moz/FF side of things? No browser is perfect, and no
browser renders 100% currect, so implying that IE is broken and others
are not to some degree is just unnecessary bias we don't need here.

The fact is, IE sometimes displays things correctly where FF and NN
fail, and vice versa. It's a two, not one, way street.

It may be a two-way street, but there are 20 lanes in one direction
and only one in the other.

Firefox is not perfect, but it implememnts vastly more of the
standard (flawed as it is) than IE. Take a look at this:
<http://www.webdevout.n et/browser_support _css.php>.

--
Chris F.A. Johnson <http://cfaj.freeshell. org>
=============== =============== =============== =============== =======
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

[Wayne Poe]

Chris F.A. Johnson wrote:

On 2006-08-30, Wayne Poe wrote:

>Andy Dingley wrote:

>>Daniel Kabs wrote:

I can not believe that CSS fails on simple problems like this.

It doesn't fail, it just takes a different approach to being asked
to do the impossible. If you make a design that needs a certain
minimum width to function, then how can it be expected to render in
a smaller space? _Something_ has to give.

The <tableversion fails because it preserves the table minimum
width at the cost of overflowing the page -- which is still a
failure from a usability viewpoint. It's no better or worse than
CSS, it's just different. If you want this sort of behaviour, set
min-width on the container element.

>>IE is of course just broken.

How bigoted this last statement is. Do you know who many problems
I've run into on the NN/Moz/FF side of things? No browser is
perfect, and no browser renders 100% currect, so implying that IE is
broken and others are not to some degree is just unnecessary bias we
don't need here.

The fact is, IE sometimes displays things correctly where FF and NN
fail, and vice versa. It's a two, not one, way street.

It may be a two-way street, but there are 20 lanes in one direction
and only one in the other.

I'm sorry, but when STRICT HTML 4.01 is used i na page, this is just
wrong. I'd pose alsmot a nequal amount of "lanes" either way, as I've
run into countless problem on the NN/Moz/FF side.

Firefox is not perfect, but it implememnts vastly more of the
standard (flawed as it is) than IE. Take a look at this:

It's far from perfect. It's not a bad browser, don't get me wrong, but
it is not near as perfect as many tout it to be. Neither is IE, or NN,
or Opera, or most any browser. FF & co do many unepcted things and so
does IE. FF is no closer to 100% compliance than IE is. There is a big
difference between rendering as epected and rendering according to the
specs.

[Chris F.A. Johnson]

On 2006-08-30, Wayne Poe wrote:

Chris F.A. Johnson wrote:

>On 2006-08-30, Wayne Poe wrote:

>>Andy Dingley wrote:

....

>>>IE is of course just broken.

How bigoted this last statement is. Do you know who many problems
I've run into on the NN/Moz/FF side of things? No browser is
perfect, and no browser renders 100% currect, so implying that IE is
broken and others are not to some degree is just unnecessary bias we
don't need here.

The fact is, IE sometimes displays things correctly where FF and NN
fail, and vice versa. It's a two, not one, way street.

It may be a two-way street, but there are 20 lanes in one direction
and only one in the other.

I'm sorry, but when STRICT HTML 4.01 is used i na page, this is just
wrong. I'd pose alsmot a nequal amount of "lanes" either way, as I've
run into countless problem on the NN/Moz/FF side.

> Firefox is not perfect, but it implememnts vastly more of the
standard (flawed as it is) than IE. Take a look at this:

It's far from perfect. It's not a bad browser, don't get me wrong, but
it is not near as perfect as many tout it to be. Neither is IE, or NN,
or Opera, or most any browser. FF & co do many unepcted things and so
does IE.

FF does far fewer unexpected things -- if you expect compliance
with the specs.

FF is no closer to 100% compliance than IE is.

That is nonsense.

There is a big difference between rendering as epected and rendering
according to the specs.

If you expect pages to display the way they do in IE, then you will
be disappointed with FF. If you expect pages to be displayed
according to the specs, you will by disappointed with IE.
--
Chris F.A. Johnson <http://cfaj.freeshell. org>
=============== =============== =============== =============== =======
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

[Daniel Kabs]

Andy Dingley wrote:

>I can not believe that CSS fails on simple problems like this.

It doesn't fail, it just takes a different approach to being asked to
do the impossible.

I reworked the example

http://www.mobotixserver.de/~daniel/..._float_en.html

and now you can easily see that I am *not* asking the impossible.

Please have a look at the last table on the page. The upper right cell
contains text and floated elements. The latter take up no space and as
such do not contribute to the table cell width. So even if the browser
window is large enough, the text overlaps the floated elements.

How can I make the browser use the space that is available, increase the
table width automatically to display text and floated elements next to
each other?
Cheers
Daniel